Am Montag, den 15.06.2009, 13:26 -0700 schrieb Thomas Powell:
> 2) Body Usage
>
>
> <nostyle>
> <h2>Warning: Styles required for correct rendering</h2>
> </nostyle>
HTML is first, and foremost, a semantic language. Why should
presentational information affect the semantics ?
Also, several further questions:
* How should an audio-based UA render this ?
* What if an UA only supports only old CSS ?
* What if an UA only supports a subset of CSS ?
* What if an UA supports another styling language ? Shouldn't the
proposed nostyle tag indicate for which language support is
"needed" ?
* And of course: What is the benefit of locking out potential
viewers ? There sure is no benefit for the user having a client
like links2 or lynx.
> Why bother? You can just do this
>
> .nostyle {display: none;}
>
>
> <h2 class="nostyle">Warning: Styles required for correct
> rendering</h2>
Even this is stupid. Progressive enhancement is *always* possible with
CSS. So why alert the user ?
> The network request happens regardless of situation no assuming images
> on. This of course makes the idea of
>
> <h2 style="display:none;"><img src="error.php?style=off">Warning:
> Styles required for correct rendering</h2>
>
> kind of useless.
I see no use case for any of this.
> Obviously detecting style availability is no problem using JavaScript,
> just measure some style region or compute a style. However, in the
> absence of JavaScript it is actually somewhat of a challenge to detect
> this case you have to look for dependent requests as a clue like some
> style only available background-image or something.
Why bother ?
> These corner cases aren't necessarily the main concerns, a serious
> motivation for this element is also because of some of the nonsense I
> am observing with background-image and content property near abuse by
> CSS wonks. It appears that there is a fairly decent sized camp of CSS
> for everything and this element might help mitigate some problems
> stemming from this. For example, using the content property can be
> somewhat troubling if style is removed. For example, consider what
> happens if you are putting in field required indicators
>
>
> input[type=text].required:before {content: " (*) "}
Use the Web Forms 2.0 property, not the class name here. HTML is
semantic.
> or for offsite links
>
>
> a[href^="http://"]:after {content:' ( Offsite Link )';}
Browsers show this to users, e.g. in the status bar.
> or any other dynamic insert this way.
Any dynamic insert should be presentational and not add any semantic
value (actual content).
> In my book effort I am seeing tremendous interest in the design
> community with such rules. Without style you lose valuable data
Without style, even a mediocre-designed site works well.
> and there is no easy recourse to present this situation at least not
> one without using JavaScript. At least having warnings via a nostyle
> element would be assisitive in informing users that this isn't quite
> right and in some cases I might dream up helpful for accessibility in
> light of too much CSS abuse.
I can't parse this line of thought. Please explain again.
> Just an aside: The content property is the CSS cousin of
> document.write if you think about it, useful but problematic.
It really isn't (or shouldn't be used as such). document.write can
change the semantic structure of the document. The content property
cannot anything in this regard; just try changing the DOM with content.
> So given that noscript correctly acts in masking content for user
> agents supporting and not for those off or unsupporting, the nostyle
> element seems like a quite logical solution for the other technology
> key client-side tech.
Urgh, no. Javascript is Code that may actually do something and is
highly site-specific, CSS is usually interchangeable styling.
> Anyway if this were an acceptable addition, tag syntax would be quite
> simple would only have common attributes, pretty basic replication of
> noscript prose in the specification. Though of course this is one
> element that would require browser changes, no quick simulation with
> JS.
Last Question: Why should anyone implement this ?
> Comments?
I think its a poorly-thought-out idea that does not serve the interests
of the users in any conceivable way. Also, the problem of
backwards-compatibility is completely unaccounted for.
--
Nils Dagsson Moskopp
<http://dieweltistgarnichtso.net>
