[whatwg] nostyle consideration
Proposing nostyle in the spirit of noscript Examples 1) Head Usage nostyle meta http-equiv=Refresh content=0;url=/errors/stylerequired.html /nostyle 2) Body Usage nostyle h2Warning: Styles required for correct rendering/h2 /nostyle The Obvious Push Back - Why bother? You can just do this .nostyle {display: none;} h2 class=nostyleWarning: Styles required for correct rendering/h2 And yes while that is true and for many situations will work fine, there are other cases you won't and you can get a sloppy or even bad results because of rendering engine paths. For example, because style is not applied until later you have an issue here h2 class=nostyleimg src=error.gifWarning: Styles required for correct rendering/h2 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=offWarning: Styles required for correct rendering/h2 kind of useless. 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. 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: (*) } or for offsite links a[href^=http://]:after {content:' ( Offsite Link )';} or any other dynamic insert this way. In my book effort I am seeing tremendous interest in the design community with such rules. Without style you lose valuable data 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. Just an aside: The content property is the CSS cousin of document.write if you think about it, useful but problematic. 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. 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. Comments? -Thomas Powell
Re: [whatwg] nostyle consideration
On Mon, Jun 15, 2009 at 2:14 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Mon, Jun 15, 2009 at 4:26 PM, Thomas Powelltpow...@gmail.com wrote: Proposing nostyle in the spirit of noscript Examples 1) Head Usage nostyle meta http-equiv=Refresh content=0;url=/errors/stylerequired.html /nostyle 2) Body Usage nostyle h2Warning: Styles required for correct rendering/h2 /nostyle The reason that noscript worked is because (IIRC) it was introduced at the same time as script. All browsers that supported script also supported noscript. nostyle would cause all legacy user agents to render the content even if they supported styles just fine. Yes in the absence of our time machine it seems a bit late doesn't it. And yes while that is true and for many situations will work fine, there are other cases you won't and you can get a sloppy or even bad results because of rendering engine paths. For example, because style is not applied until later you have an issue here h2 class=nostyleimg src=error.gifWarning: Styles required for correct rendering/h2 The network request happens regardless of situation no assuming images on. That doesn't seem like a very serious issue. Just don't use images if you care that much. A large percentage of non-CSS browsers are probably text-based anyway. It isn't but hints at what the motivation was from a real world request (see below) 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: (*) } This should just use HTML5's required attribute instead of a class: http://dev.w3.org/html5/spec/Overview.html#the-required-attribute Agreed that is the case, this is more documenting the usage of designers not that there isn't an HTML 5 appropriate solution. Conformant browsers should make it clear to the user that the field is required even if styles are disabled. yes they should. or for offsite links a[href^=http://]:after {content:' ( Offsite Link )';} This is non-essential info, and every browser I've heard of exposes it anyway (e.g., by hovering over the link and looking in the lower left). or any other dynamic insert this way. Do you have any other examples where this is a significant issue? Those two don't seem like a big deal to me, honestly, even if it were logistically possible to get nostyle supported widely enough to be useful. Those were just examples of more valid uses of content actually. Of course as I mentioned below people can abuse this property and then it does become a big deal. But dynamically having content jam in all sorts of stuff client-side seems wrong-headed so I certainly don't suggest codifying bad practices though mitigating them somehow seems appropriate. If CSS is necessary for a site to operate, it's probably being misused. If an author is misusing CSS this badly, it's not clear to me why they could be expected to reliably use nostyle. The contents of nostyle also don't make a difference to almost anyone, so authors who use it won't really understand the purpose it serves and it will probably be misused more often than used. You may be quite right. Understand my purpose of proposing this was mostly due to some contrivances to determine style and no-style support for an effort which is very contingency concerned. The solution that was adopted using scripting, server-side logging particularly triggered by image requests from background-image values or their absence, etc. can figure all cases but it was a mess and thus the why not have a nostyle wouldn't life be easier So from where you sit yes it is not that important likely, from having to wrestle with it I would have loved to have an easy solution. Anyway I will say that there is a bit of symmetry of having on/off cases for all the various client-side technologies (img, script, object, etc.), but I see that the off aspect of style could simply be thought of as the markup itself and that is certainly fine it has worked for most so far.
Re: [whatwg] nostyle consideration
On Mon, Jun 15, 2009 at 4:23 PM, Kornel Lesinski kor...@geekhood.netwrote: On Mon, 15 Jun 2009 21:26:21 +0100, Thomas Powell tpow...@gmail.com wrote: 1) Head Usage nostyle meta http-equiv=Refresh content=0;url=/errors/stylerequired.html /nostyle 2) Body Usage nostyle h2Warning: Styles required for correct rendering/h2 /nostyle Purpose of this element seems to make lack of CSS not my problem instead of providing meaningful alternative. This is not helpful for users without CSS. It only helps authors to discriminate against them, and I'm strongly against it. There is no intention of that in the proposal, you seem to have eliminated the discussion about dynamic content which is also discrimentory of such users as well as well as the error reporting examples. I showed a variety of negative and positive cases. My interest here in this tag in fact has grown out of a problem with lack of understanding of users with various capabilities rather than some particular design or tech agenda. Comments? noscript is a very poor solution, and nostyle would be too. You should use graceful degradation/progressive enhancement instead (in both cases). Couldn't agree more about the architecture, if you read any of my books particularly my Ajax one I am strong proponent of falling back not locking out, but obviously that choice is philosophical not technical. A negative lock out approach can be accomplished whether or not this element exists though as you say it makes it easier for some to treat a class of users bad. While I am not sure that markup elements can really force a philosophy of Web design/dev though they can certainly encourage it and so I understand the passion of not wanting to enable tech abusers any more than we have to, so point taken, but it actually doesn't fit with my experience. Consider your opinion of the value of noscript for me I have to disagree it has been quite valuable. In fact my main use is simply to show people about the reality of people turning things off or not supporting script rather than letting them cite arbitrary hear say about the issue. We have customers that have used it just to quantify exactly what you are worried about - down level user-agents or script off folks. It has really helped me get people on board with seeing the realities of addressing such contingency cases. Log files could certainly do this too but in the age of script based Google analytics unlikely for most. Given the blissful ignorance about measuring script use it would be great to see a noscript tag (or maybe even this dreaded nostyle) being employed for good because in many cases the discrimentory use of Web tech changes once people see the traffic they fail to serve properly to in a measurable manner rather than an abstract statement about what they ought to do (at least rational corporate types act that way if experience is a judge). Anyway I am sure you can think of a bunch of bad uses of JS, but that if anything only proves the point of the need, if a site owner is going to be restrictive for better or worse it would be better to be aware of your choice in a quantifiable way and error to your users properly? In short I simply view this nostyle element simply as a symmetrical element to other aspects of Web tech: on state/off state that's it. It can be used for good or ill like most anything and it actually supports a view of awareness of all rendering cases by its mere availability. Judging by comments it would appear that some view the style off state of being handled just fine with plain markup. -Thomas -- regards, Kornel Lesinski