- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 11 Jan 2008 11:11:11 -0800
- To: David Dorward <david@dorward.me.uk>
- CC: CSS Style <www-style@w3.org>
David Dorward wrote: > > On 10 Jan 2008, at 18:42, Andrew Fedoniouk wrote: >> Christoph Päper wrote: > >> But I am always wondering why people think that word 'style' is only >> about visual style. >> It could be behavioral style too. And behavioral style can be related >> to visual style. >> In case of <input type="range"> @step may trigger appearance of spin >> buttons. Which are also related to visual style. > > When function is specified, it is expressed using form. CSS is > concerned with the form, HTML is concerned with the function. > > <h1> may trigger the appearance of large font sizes, which are visual > style - but CSS lets you say "Use a larger font size" not "Be a top > level heading". > > It might be reasonable to add something to CSS that causes spin > buttons to be rendered, but setting bounds for a control is function, > not form. Oh... overflow:auto; may trigger scrollbars. This scrollbar... is it form of function? And yet consider following: input[type="currency"] { color:black; @format:"$n,nnn.nn"; } input[type="currency"]:negative { color:blue; @format:"$(n,nnn.nn)"; } Could you try to define 'color' and '@format' in terms of form/function ? I am asking simple thing in fact: CSS mandates that vendor specific attributes shall start from '-' sign. What is the desired format of page(application) specific attributes then? IE allows you to define and retrieve any custom attribute in CSS. In FF they are not getting into CCSOM at all. Shall we recommend UA to support custom (page/application specific) attributes(and probably states) or not? If yes then what is the format? And think about elements defined in WebForms module (HTML5). At least those elements have their specific states that needs to be styled separately. We can try of course to define all possible states upfront. But is it wise or even feasible? -- Andrew Fedoniouk. http://terrainformatica.com > >> 2) keep HTML as purely semantic language. > > A potentially worthwhile goal, but making HTML purely semantic at the > expense of stopping CSS being purely presentational would be one step > forward and then another step back. >
Received on Friday, 11 January 2008 19:11:38 UTC