Slashdot Mirror

What the heck are you talking about? What is it that you're saying you should be able to do with this HTML that you can't do with frames in the same amount of code?

But besides the first point's incomprehensibility, the second point:

But no sir! They even had to remove the target attribute from XHTML Strict! Notice how my code would have been XHTML+CSS valid without this restriction that makes me write more hacks (rel="external" and an ugly JS to add the target attributes on page load).

...is ridiculous. If you need the target attribute so badly, use HTML 4.0 Transitional or xhtml 1.0 Transitional. No problems. Better yet, if you're using frames, why not use the right doctype in the first place? iframes and target attributes are alive and well in xhtml 1.0 Frameset...

http://www.w3.org/Provider/Style/URI

Shouldn't obsolete TLDs just be mothballed with further registrations prohibited?

It's not just a case of registering new domains for all those sites - think of the volume of inbound links that will break if a whole domain just vanishes overnight.

No, it's not. It's called the plain view exception and has been found to be completely constitutional. I refer you to this page from the Justice Department (ok, no snickers) which references Horton v. California, 496 U.S. 128 (1990).

The relevant part is as follows:

To rely on this exception, the agent must be in a lawful position to observe and access the evidence, and its incriminating character must be immediately apparent.

How this exception would apply in the current situation will be up for debate but the exception of an officer finding evidence of another crime, while executing a search warrant for a different crime, is fully constitutional. For a further reading of just this subject, see Danny Weitzner's comments with a much more detailed discussion of the plain view exception.

What, you expect the cops to ignore the dead body missing its arms lying in the back room because they were only looking for the stash of cocaine in the house?

They could call it -ie-border-radius if they don't like implementing a working draft. But it's already defined: http://www.w3.org/TR/2005/WD-css3-background-20050 216/#the-border-radius It's very similar to -moz-opacity, which is now in the CR: http://www.w3.org/TR/2003/CR-css3-color-20030514/# transparency

They could call it -ie-border-radius if they don't like implementing a working draft. But it's already defined: http://www.w3.org/TR/2005/WD-css3-background-20050 216/#the-border-radius It's very similar to -moz-opacity, which is now in the CR: http://www.w3.org/TR/2003/CR-css3-color-20030514/# transparency

oh well, at least they are updating HTML, should be interesting:

"...In November 2006, the HTML Working Group published a new charter indicating its intent to resume development of HTML in a manner that unifies HTML 4 and XHTML 1, allowing for this hybrid language to manifest in both an XML format and a "classic HTML" format that is SGML-compatible but not strictly SGML-based. Among other things, it is planned that the new specification, to be released and refined throughout 2007 through 2008, will include conformance and parsing requirements, DOM APIs, and new widgets and APIs. The group also intends to publish test suites and validation tools.[8]"

http://www.w3.org/2006/11/HTML-WG-charter.html

The current Working Draft of the CSS3 Values and Units module allows for a calc() function that permits this behavior. Generally, yes, many things would be easier if an embedded programming language would be allowed, but this would potentially come at a significant speed cost. Part of the idea behind CSS is that it should not greatly slow down rendering as compared to simpler layout schemes.

Usually I'm content just to read other people's comments and letting the Slashdot market-force correct misconceptions, but you, sir, have forced my hand. I know there's already an good reply by another poster, but here's my take.

As many have said in this string of posts, without the use of tables, it is no longer a job for the general web creator to create a three column lay out, without being a complete CSS guru and even for them it gives them headaches.

Umm.. no. Among the many ways one can do this, one of the simplest one will take all of.. four divs, 1 parent and 3 contained siblings. If you want more precise controls, then of course, you have to delve deeper into the levels of complexity - but how is this different from so many sites using meshed colspans and rowspans just ot get elements positioned just the way you want it?

In my estimation, what the designers of CSS have managed to do is crush the life out of the promise that once was the a usable, if slightly clumsy, way to present information.

Yes, yes.. as much I hold your esteemed estimation in the highest regard, I must respectfully point out that CSS allowed us to break free of having to litter our pages with a myriad of <font>, <b>, and <i> tags, not to mention repeatedly setting the same properties to all elements of the same class by hand. Oh, and you want to change the background color of every single one of 20 pages? Good luck to you sir!

And that was just some examples of the uses of CSS; semantic groupings of logical 'classes' of elements, and separation from content, which makes it easier to apply the same style to many different pages with different content. it's not even taking into account the finer grain of control one gains over your element - how would you postion your company logo exactly at co-ord (10, 15) without CSS or VB/Javascript? How would you specify links to turn bold on mouseover? Oh, I'm sure you'd prefer the good ol' days of the <blink> tags and HTML-only formatting, but people these days a somewhat more demanding taste..

As an example. Using un-ordered lists to create menus. Its a complete and total hack, and I mean to use the word hack in the most derogitory manner possible. Instead of comming up with a menu framework that was designed from the ground up to be menus they used this stupid hack and think they are so cool. News for you, your not cool, your not smart nor are you clever.

Ignoring that rather high-schoolesque remark at the end.. What *is* a menu, if not a list of choices? What do you think it's stored as for most applications? Heck, how else do you think it's stored in a Javascript menu (hint: arrays are a kind of ..)? What CSS does is to take that unformatted list, and makes it look slick and polished for the user. What would you prefer, tables for menus?

As for the comment about a new framework for menus.. may be workable I guess. But still, what's the point of coming up with so many specialized tags? Yes, it will have to be a HTML tag - unless you meant taking that UL and making it display like a menu, which of course, by your definition, would be the 'most deragatory manner of hacks'.

There are elements of CSS that are quite functional and workable, but for the most part its just a cludge and a bad one at that. Lets take for example something that could make all of our lives easier, the basic ability to have include files.

I'm sorry.. you hadn't heard of @import? Oh, you meant content including? Pray tell, how/why is CSS supposed to handle content? Sometimes I wonder if you know the difference between CSS & HTML, and which you're ranting against..

All you CSS lovers hate frames and you hate tables.

Um.. no. Frames are fine actually. They're a bad way to do things, b

oh well, maybe CSS 3 will fix somethings?

Maybe. Layout tables are going into CSS. The syntax looks like this:

body { display: "a@@" "@@@" "@@b" "@@@" "c@@" "@@@" "@@d" }

Sort of like COBOL meets HTML. This does not look promising. Nor does it look well-defined.

For improved accuracy, replace "isn't 100% effective" with "is 0% effective (or nearly so)".

Useful how, exactly? You won't make .com significantly cleaner (since countries that don't have such laws would be free to point a .com domain at porn), and you'll put your own country's porn companies at an economic disadvantage.

Legislating the use of top-level domains for content filtering makes about as much sense as legislating the use of chisels as screwdrivers. If you want to legislate something, at least legislate something that is actually designed for filtering.

The problem isn't filtering content. The problem is that domain names are a terrible way to do it (see RFC 3675), and there are better ways of doing it (see PICS).

As for a voluntary .xxx, the public and legislators will misunderstand its limitations. It's practically begging for bad law. It's better not to set it up in the first place.

I have made this suggestion a number of time in the past. Maybe I should look into what it would take to get it drafted into an RFC?

No need. There is already a standard: Platform for Internet Content Selection (PICS)...

You're incorrect. Go read the w3c spec for HTML4. Pay specific attention to the "Start Tag" and "End Tag" notations below each element definition.

Markup is made of elements, which when explicitly placed in the markup all have a start tag. Some elements also have an end tag, which is sometimes optional. Some elements are implied when their tags are omitted.

Yes, there is wide spread misunderstanding of the word tag, and you're one of the people doing it.

Actually, when the average developer uses the word "tag", there's about a 70% chance they mean "element type", there's about a 20% chance they mean "element", there's about a 8% chance they mean "attribute", and only a 2% chance they actually mean "tag". The abuse of this term is so prevalent that it's a running joke in the NOT the comp.text.sgml FAQ.

The word "tag" is actually a genuine technical term. It's the delimiter that marks the beginning and end of elements. In other words, the actual text "<foo>" that appears in the document. The element is a particular instance of an element type found in a particular document. The element type is (shock) the type of element - a paragraph, an image, a table, etc. The terms "tag", "element" and "element type" are not only dissimilar, they are working on completely different conceptual levels. One is at the syntactical level. One is at the document structure level. One is at the markup language level. Totally different things.

Funnily enough, this distinction is explained in the HTML 4 specification because so many people get it wrong. So next time you see somebody abuse the word "tag", you'll know how familiar they are with the HTML 4 specification (i.e. not at all).

"html/xml tags"

For which I'm pretty sure the proper term is "element."

Microsoft could have built in functionality for parents to allow use of TIGRS self-certification, just as it built support for PICS labels generated by ICRA's form into IE.

Your tears are so yummy and sweet!...Oh, the tears of unfathomable sadness!
-Cartman

The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists).

What is your DOCTYPE in your html? Browsers usually have two layout modes depending on your DOCTYPE.

But to standardize the format of tags and to standardize how to exchange tags between systems, is a great idea.

Great idea. Have you ever heard of XML?

(Since the problem we'd like to solve is hard, let's solve an easy problem instead. Even though that's been done already.)

The Annotea Project is a W3C project that ties together standards that allow attaching metadata to web pages without altering the contents of the object.

The Amaya web browser/editor is a W3C project that serves as a testbed for the consortium's standards - including an annotea implimentation (the most interesting part of the project imho).

Basically, you can keep your own local metadata, or have a central shared resource with that implimentation. Of course, you could build your own implimentation that has other properties (merging/sharing annotations/tags etc...)

The Annotea Project is a W3C project that ties together standards that allow attaching metadata to web pages without altering the contents of the object.

The Amaya web browser/editor is a W3C project that serves as a testbed for the consortium's standards - including an annotea implimentation (the most interesting part of the project imho).

Basically, you can keep your own local metadata, or have a central shared resource with that implimentation. Of course, you could build your own implimentation that has other properties (merging/sharing annotations/tags etc...)

This is what RDF is for. You distinguish between your idea of the "fud" tag and somebody else's idea of the "fud" tag because the relationships are expressed as URIs. You refer to the subjects of the tagging with URIs too, meaning that you don't need special tagging behaviour built into whatever you are tagging - you just need a URI to point to. And because you can put an RDF file anywhere, it's totally decentralised.

This has already beeen designed and implemented in Amaya and Annotea by the W3C. The correct place to solve this is in the client, not in each individual website.

This is what RDF is for. You distinguish between your idea of the "fud" tag and somebody else's idea of the "fud" tag because the relationships are expressed as URIs. You refer to the subjects of the tagging with URIs too, meaning that you don't need special tagging behaviour built into whatever you are tagging - you just need a URI to point to. And because you can put an RDF file anywhere, it's totally decentralised.

This has already beeen designed and implemented in Amaya and Annotea by the W3C. The correct place to solve this is in the client, not in each individual website.

Regardless of the reasons: if you reference a file on someone's site, it's hardly their fault if they move/change/delete it, and it breaks your stuff.

That's not what Tim Berners-Lee thinks.

That's just wrong, you should try software authored by folk who know what they're doing.

It's called a non-validating processor and it's totally compliant with the XML 1.0 specification.

If they did, they'd be violating accessibility. Not only is authentication that the user is sighted against W3C's rules, but it's also a potential violation of disability discrimination bans.

Mod parent up. Last year, I got a 1920x1080 display at home and work, and the most jarring thing was reading webpages, because they're all very tall and relatively narrow (most are designed for something closer to 1024 pixels wide). The trend these days is for larger monitors, so that ultimately means excess horizontal space, regardless if your display is 4:3 or 16:9/10.

Ultimately, HTML should may solve the problem by making it possible to automatically add extra columns to fill the width like newspapers do. But, still... the die is already cast, HTML is very oriented towards vertical scrolling, and widespread adoption of multiple columns is a long way off (eg. Mozilla is the only browser that supports it currently).

Have fun with you code and don't hate it :) hate the things that don't comply to the standards...

Sorry, but that site looks awful in firefox and konquerer (meaning that it probably doesn't
look right in other khtml based browsers either). I really can't imagine that you meant it to look like this.

A good idea to make site work well everywhere is to run them through html validator at http://validator.w3.org./ When it passes the test, test it in whatever browsers you plan to support, if something doesn't work, remove or change the feature in a way that the page validates correctly.

This gives you the best chances that your site will work even in browsers that you haven't tested.

Currently your site generates 1024 errors when validated.

W3c have also similar test for validating CSS. Use it and then remove or make adjustments so that it works in the browsers you officially intend to support but still passes w3c tests.

BTW, IE regardless of version is a disaster, when it comes to supporting CSS.
Just try http://www.webstandards.org/files/acid2/test.html.
Firefox will not work properly either, but it is far better than IE. Konquerer passes acid2
and probably others based on KHTML such as Safari, Opera is supposed to work as well.

I really wish browser manufacturers would start to support CSS properly, it would make it so much easier to build and maintain good web sites.

Just because some academics came up with a "standard" doesn't mean there's a law that says that everyone needs to follow it.

Two comments about that statement. First, w3c standards weren't just made up by academics. If you take a look at the member list, all of the major players are there - IBM, Microsoft, Sun, Intel, Mozilla, etc. There's a long process of debate and editing that goes into those standards.

Second, though true that there isn't a law that everyone needs to follow, there are laws that apply in some countries. How widely it applies depends on the country, but many laws either directly or indirectly reference WCAG guidelines - one of which states: "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported."

No, textContent of DOM 3 is more like the old innerText. It makes a single plain Text node within the element. I want to take a string of HTML, deserialize it into a tree of nodes, and then hang it on a given element. I can do the last step with appendChild, but what should I do to parse the HTML? Should the parser be written in JavaScript and sent to the client, with the runtime overhead of interpretation and a separate copy loaded into memory for each tab of each window, just because the DOM has no "standard" way to parse HTML?

The many standards for web browsers (of which HTML is just one) is laid out by the World Wide Web Consortium, not by a lofty group of "some academics". And guess what, Microsoft is a member of the consortium. So why has MS done such a horrible job at supporting the standards that they had (or at least could have had) a hand in developing?

The many standards for web browsers (of which HTML is just one) is laid out by the World Wide Web Consortium, not by a lofty group of "some academics". And guess what, Microsoft is a member of the consortium. So why has MS done such a horrible job at supporting the standards that they had (or at least could have had) a hand in developing?

The textContent property is defined in DOM Level 3. Microsoft has never claimed to support that recommendation, and neither Apple nor Opera claim support for it either. Gecko supports it, although the documentation doesn't make it clear that it's from DOM Level 3. If you write code using features supported by only one browser, then you can hardly complain if it doesn't work on other browsers. What you've done is no different from a developer who codes only for IE-specific features, and then whines when they don't work on Firefox.

Coding to standards is important, but you're better off coding to the standards that have been implemented. Otherwise you're just playing with the cool new stuff that you like, and that's not how work gets done in the real world.

Hm. Seems textContent is old and in w3 DOM spec?
http://www.w3.org/TR/2001/WD-DOM-Level-3-Core-2001 0913/ecma-script-binding.html
And it *is* true that recursively fetching text data is a bit of a hassle. Not a huge one though.

How about "recommendations"? Anyway, for IE's implementation to be considered an actual standard, and not a buggy mess of badly implemented features, Microsoft would have to publish the details of how their rendering engine works. How am I supposed to code to an undefined standard? Trial and error only gets you thus far.

Since date and time information isn't included in TCP/IP packets, this kind of attack won't work for all services. Assuming that the "hidden servers" in question are HTTP servers, there is a rather simple workaround: simply disable sending the "Date" header. This can probably be accomplished with mod_headers in Apache, but I've never tried using it myself. Oddly enough, the server would still be standards compliant. Obviously, servers that leak the current time by some other means would still be vulnerable.

A simpler, less precise attack of this nature would simply be to continuously ping the suspected server via both Tor and the public internet. If they (reproducibly) fail at the same time (and we could launch a denial-of-service attack to make it fail), they're probably the same machine. Attacks of this nature might even be able to confirm if a hidden server is on the same network as another computer.... But any of these attacks require someone to suspect you of running the server in the first place—and if they do, you probably have bigger problems to worry about.

The bottom line is, as Tor's manual clearly indicates, having a hidden server machine accessible from both Tor and the internet is a bad thing. Operators of hidden services should use a dedicated machine and block all incoming traffic (on all TCP and UDP ports) that is not via Tor.

It's been done before and is not a new idea.

PICS labels have been around since 1996, and were proposed to label for language, violence, and sexual content (among others).

ASACP RTA is another labelling scheme from 1996.

ICRA labels have been doing the same since 1999.

RTA and ICRA are in active use today. PICS fell mostly away (to my knowledge) -- probably because it wasn't just for filtering, but for any kind of content tagging. Being a general solution doesn't get the "save the children" mouth-breathers behind you.

The problem with the rel=nsfw is that it is binary. I can't establish any kind of scale for what I want to see (nudity is okay, sex acts are not), and it only filters in one dimension (I can't say that I am okay with sex, but not with violence, or vice-versa for the U.S.A.).

It's been done before and is not a new idea.

PICS labels have been around since 1996, and were proposed to label for language, violence, and sexual content (among others).

ASACP RTA is another labelling scheme from 1996.

ICRA labels have been doing the same since 1999.

RTA and ICRA are in active use today. PICS fell mostly away (to my knowledge) -- probably because it wasn't just for filtering, but for any kind of content tagging. Being a general solution doesn't get the "save the children" mouth-breathers behind you.

The problem with the rel=nsfw is that it is binary. I can't establish any kind of scale for what I want to see (nudity is okay, sex acts are not), and it only filters in one dimension (I can't say that I am okay with sex, but not with violence, or vice-versa for the U.S.A.).

The person who decides if something is SFW should be the web reader, not the author, because what's safe for me may not be safe for you.

The web author should determine the nature of the content. For example class="grotesque", class="sexually", or rel="hateful". Of course a tag can have multiple classes. If something like this is promoted i hope it's in concert with movie, tv, music, and game rating systems.

One problem with using class is that that you are turning a generic words with user defined meaning into a reserved words whose scope is understood by all web browsers.

XHTML should really have something better for rating content. The PICS[1] project looks promising.

[1] http://www.w3.org/PICS/

The rel attribute is designed to specify a forward relationship with the current document.

"rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types." http://www.w3.org/TR/html4/struct/links.html#adef- rel

"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details." http://www.w3.org/TR/html4/types.html#type-links

The rel attribute is designed to specify a forward relationship with the current document.

"rel = link-types [CI]
This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types." http://www.w3.org/TR/html4/struct/links.html#adef- rel

"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details." http://www.w3.org/TR/html4/types.html#type-links

You mean like PICS?

why not have nsfw.txt?

Magic URIs are a poor design. robots.txt was a mistaken hack, not something to be emulated.

This relies on the people making links to use the NSFW tag or the guys making content to use it. Frankly, I don't see it ever being used properly.

There's plenty of places where NSFW is specified in link text already. This is just a way of making it machine-readable.

how about a universal close tag for the last opened tag

Such shortcuts have already existed since HTML 2. These have been universally ignored by browser developers.

Not sure if you, or anyone else, will see this, but I figured I'd respond in case you do.

There are multiple ways. The main one I was thinking about was simply defining a "handheld" stylesheet. For websites, the common way someone is going to view it would be using the "screen" media type. But you can also define other media types, like "print", "projection", "aural", and other things. You can find a list of them in several places. The one for mobile devices would be "handheld." The idea is that the content will simply transform how it displays based on how you are seeing it.

Slashdot uses a handheld media type in one of its stylesheets. Honestly, I've never tried visiting it with a handheld, but I guess they are doing it.

There is a very recent article on alistapart.com that uses javascript to change the layout based on the screen size, but in the case of mobile devices, many may not be able to run the script, so it's use is questionable.

The W3C also has defined the "best practices" for mobile devices, and there are couple of different ways to check them. In these cases, you'd pretty much have to deliver different content if their user-agent shows up as a mobile device, which would require scripting.

If you are serving different content, you can use the specialized version of xhtml for it.

Hope this helps.

That's not 'deep-linking', you moron, because it's not linking at all.

A 'link', in HTML, is a <a href="...">, or, as not often used, <link href="..."> in the head. And sometimes the longdesc attribute that absolutely no one uses, and probably some other obscure things. That is what 'linking' is.

Including images is not 'linking', of any sort. Embedding video is not 'linking', of any sort. A 'link' is something end users follow in HTML to go somewhere else. But let's just see what the w3c says about in the link I have cleverly provided. Then read here to see what it says about images and see if it calls including images 'linking' to them. It says images can have links around them, and they can have image maps with links, but absolutely no reference to <img> or <object> as 'links'.

'Deep-linking', as is commonly used, means 'linking into a web site far away from the root', where 'far away' is somewhat subjective. It does not mean 'representing another site's content as your own', for the obvious reasons that doesn't even make any sense...what if you presented their front page or an image on their front page, from their root, as your own? That could hardly be called 'deep'.

This site did deep-link, in the correct sense...it was to non-html documents, but they were, indeed, links and not included within a web page.

That's not 'deep-linking', you moron, because it's not linking at all.

A 'link', in HTML, is a <a href="...">, or, as not often used, <link href="..."> in the head. And sometimes the longdesc attribute that absolutely no one uses, and probably some other obscure things. That is what 'linking' is.

Including images is not 'linking', of any sort. Embedding video is not 'linking', of any sort. A 'link' is something end users follow in HTML to go somewhere else. But let's just see what the w3c says about in the link I have cleverly provided. Then read here to see what it says about images and see if it calls including images 'linking' to them. It says images can have links around them, and they can have image maps with links, but absolutely no reference to <img> or <object> as 'links'.

'Deep-linking', as is commonly used, means 'linking into a web site far away from the root', where 'far away' is somewhat subjective. It does not mean 'representing another site's content as your own', for the obvious reasons that doesn't even make any sense...what if you presented their front page or an image on their front page, from their root, as your own? That could hardly be called 'deep'.

This site did deep-link, in the correct sense...it was to non-html documents, but they were, indeed, links and not included within a web page.

Good idea, how about the CSS Test Suite?

IMHO, I always thought SOAP was over engineered. Simple Web Service's are like a console program, but the input is in field form from the web, with input type checking. Output is an XML string with an embedded "xml-stylesheet" statement, (for the unwashed). The security of a simple Web Service is; Simple. A Simple Web Service already has many locked doors to slow down uninvited guests, and the other doors that the uninvited enter can be easily closed. This act from Google will reduce their maintenance cost, and should increase their band width by reducing their output to smaller chucks with the same information. The following files would be cashed on the client side, HTML, CSS, JavaScript, XSLT, and XML; So a simple change to one file, and the Client Side will download only the changed file. The Server Side has only a Simple Web Service of one input entry point, and one exit point. The Client sees faster turn-around, the Server sees a bigger band-width.

"Slowly, one by one, the Penguins steal my sanity." - Unknown