recommend that vertical-align be amended

I'd like to recommend that vertical-align be amended in one of 2 ways:

1) if the vertical-align property is specified in an element having position: absolute/fixed, that it position boxes inside it relative to its own inner dimensions; thus:

#container { position: absolute; height: 100%; vertical-align: bottom; }

<div id="container">
<div id="example">Bottom</div>
</div>

places "example" effectively at the bottom of the window.

2) A property be added that works as above in any context; for example, vertical-box-align, etc. vertical-align would be left be for backwards compatibility.

Move box-sizing to Box Model module?

http://www.w3.org/TR/2003/WD-css3-ui-20030703/#box-sizing

Wouldn't this fit better in the Box Model module?

~fantasai

I found that very strange, also. I once went looking for the box-sizing property because Opera Software's documentation didn't elaborate on the legal values. I had, shall we say, a hard time finding it. It seems to make much more sense to have it in the box model module, since that's what it relates to.

J.

Please keep 'box-sizing' in CSS3-UI!

The reference in CSS3 UI [to 'box-sizing'] should NOT be removed.

[Scott]

Whoa! Not so fast. This is the first time I've heard anyone was planning on dropping this. Why?

This new box-sizing property was something I and a lot of other developers were looking forward to. The original box-sizing model simply does not work in a lot of instances.

If I set an element to fill the viewport - ie. width: 100%; - then I cannot, with the CSS2 model, add padding to it. I either have to pad child elements, or more likely in real-world scenarios, insert an extra empty container and give it the padding instead.

What prevalent wisdom has decided we don't need this?

(note - specific implementation is not my concern, I don't care where it's applied; I just want the ability to choose my box-sizing model)

d.

What's a "pseudo"?

3.2.2. ::choices and other

----------------

What's a "pseudo"? The specification should not contain abbreviations like this. Change to pseudo-class/pseudo-elements.

'appearance'

4.1. The 'appearance' property

------------------------------

Who's idea was this? What's the purpose of this? Why not just use 'display' property with the new values?

System fonts

4.2. System fonts

-----------------

Why just fonts? What if someone wants to style the padding of the images according to the padding of system radio button? What if the other one believes the margin of his paragraph should be equal to the system checkbox-group?

how is 'display:icon' different from 'content:url()'

5.1. Additional value(s) for 'display' property

-----------------------------------------------

I guess this ought to look like this:

 p { display: icon; icon: url(blah); }

Tell me, how is this different from

 p { content: url(blah); }?

Is 'outline-offset' important?

6.5. 'outline-offset' property

------------------------------

This reminds me of the "marker-offset". Is this really important? The specification should leave this to the user agents.

'key-equivalent' problems?

8.2.1. Keyboard equivalents: the 'key-equivalent' property

----------------------------------------------------------

"There may be platform and user agent limitations to key-equivalents which conflict with those inherent in the user agent and operating system."

Great news. What about the UA behavior in this case?

"Should we include "standard" keys from other consumer computing devices?"

Could you expand on this? You call this a last call. Where's the solution? This section should be completely reworked.

document should be rewritten

Etc., etc., etc. This document is not in its Last Call. I'd say it still looks like a list of requirements. It has to be carefully reviewed and rewritten.

'appearance' is useful

'display' controls the layout of the element, while 'appearance' controls only its appearance.

You could, for example, have a row of buttons in a table-like arrangement:

   button { display: table-cell; appearance: button; }

...or you might want to keep them inline:

   textarea { display: inline-block; appearance: field; }

The two aspects are independent.

This one is pretty useful then.

Are -moz- extensions adopted by policy?

As to who thought of it, I do not remember when this was first mentioned, but Mozilla has implemented a version of this for around a year now. (As '-moz-appearance'; it is used to render the user interface in the "classic" skin so that it matches the OS.)

Is it the policy of the W3C to cover Mozilla's implementations in the specs?

what about 'padding' of radio buttons for images?

That's what 'appearance' is for; the extra fonts are useful primarily for matching the font in other parts of a document with the fonts used by controls.

Rephrasing: What if someone wants to style *just* the padding of the images according to the padding of the radio buttons?

why not use DOM for icon feature?

Functionally, the difference is limited, but in practice it is useful to be able to control the icons used in one stylesheet and have the element switch in and out of the icon representation on the fly.

I agree, that's very useful. Why not use the DOM for this?

explain what is "harder to maintain"

Note that the 'content' property will have an 'icon' value as well, so that it is possible to say:

   p { content: icon; }

The typical usage will be something like:

   #save { icon: url(save); }
   #open { icon: url(open); }
   #print { icon: url(print); }

   button { content: icon '\A' contents; }

While it would also be possible to say:

   #save { content: url(save) '\A' contents; }
   #open { content: url(open) '\A' contents; }
   #print { content: url(print) '\A' contents; }

...it is a lot harder to maintain.

Ian, could you explain what is "harder to maintain"?

For whom or for what? I'm pretty sure you didn't mean editing CSS by hand here, so what is it?

'display:icon' is useless

I consider the usefulness of the 'icon' value of the 'display' property equal to zero.

The 'display:icon' value may be removed at a later stage depending on implementation experience.

It spoils and litters the spec.

how do you know it is the most frequent?

The following rule:

   foo { display: icon; }

...is basically equivalent to:

   foo { display: inline-block; content: icon; }
   foo::before, foo::after { content: inhibit; }

Too bad. This case is just one among many. And how do you know it is the most frequent?

can only W3C members/employees request features?

Do I have to be an employee of a W3C Member organization to request properties?

stylesheet for XHTML 2.0?

What if I politely ask you to include a stylesheet for XHTML 2.0?

Dependencies on other modules

The following are Last Call comments on behalf of Cardiff Software. They are individually lettered for easy reference, and arranged by heading in the specification.

2 Dependencies on other modules

a) Section 3.1.4 contains the statement "This spec[ification] does not define what is a form element". This statement applies to multiple sections, and should be moved to a more central place, such as section 2 which deals with dependencies.

:default more than one?

3.1.1 :default

b) Please clarify: can the default pseudo-class simultaneously apply to more than one element in a group?

two buttons with same function

For example, in a set of buttons, if two of them had the same function, could they both be considered :default?

limits on group for :default?

Are there any limits or guidelines on what can make up a "group" for purposes of :default?

:valid and :invalid clarification

3.1.2 :valid and :invalid

c) Please change "the bound instance data constraints" to "data validity semantics defined by a different specification".

:in-range and :out-of-range clarification

3.1.3 :in-range and :out-of-range

d) This section speaks of "in range or out of range of the *visual* representation of the element" (emphasis added). Is it the intent that this applies only to visual media? Please change it to apply to any media. For example, an audio browser should still be able to do something useful with the :out-of-range class.

more :in-range and :out-of-range clarification

e) The text currently says "In summary: an element is :out-of-range when it does not accurately reflect the state of the model." Please change "does not" to "cannot". For example, if a form control didn't accurately reflect the state of the model just because it needed to be refreshed, etc., it would not be :out-of-range. Only when some kind of logical contradiction is present, is a form control :out-of-range.

even more :in-range and :out-of-range clarification

f) Please add a sentence along the lines of "An element that lacks data range limits or is not a form control is neither :in-range nor :out-of-range."

::value illustration please

3.2.1 ::value

g) Please add a graphical illustration of what part of a form control is styled by ::value.

::choices minor fix

3.2.2 ::choices

h) Minor editorial. "pseudo." -> "pseudo-element."

::repeat-item rewording

3.2.3 ::repeat-item

i) Current text: "Its position is as a parent to all the elements in a single repeating item." We believe this is technically correct, but awkward to read. Could the sentence be improved?

::repeat-item/index pseudo-element textual example

j) Please add a textual example showing where the pseudo-element appears.

::repeat-index as pseudo-class instead?

3.2.4 ::repeat-index

k) Reportedly, this is difficult to implement as a pseudo-element. Should it perhaps be a pseudo-class instead?

add 'submit'

4.1 The 'appearance' property

l) please add the following possible values (listed under respective broader categories)

* button

- submit

add 'signature'

- signature

add 'tab'

- tab (as in tabbed dialog, etc.)

add 'static-text'

* field - static-text (like <xforms:output>)

add 'multiline'

- multiline (like <xforms:textarea>)

add 'password'

- password (like <xforms:secret>)

add 'styled-text'

- styled-text

add 'combo-box'

We would also like some kind of appearance value to represent a "combo box" affordance, or a control that allows either selecting from a list or manual data entry.

rename 'field'

m) "field" is a confusing choice of terminology, as some users might consider several of the controls listed under "menu" also as a "field". Please use a different term, such as "data-entry".

make similar additions to 'font' property

4.2 System fonts

n) This property has the same values as the 'appearance' property. See comments l) and m).

'box-sizing' confusion

5.2 'box-sizing' property

o) This property is confusing, and doesn't add any new functionality. Please remove it from CSS3 Basic UI.

update references

Normative References

p) Please update your reference to XForms 1.0 to the latest that's available at publication time.

problems with :default, :valid, :invalid

3.1.1 :default

3.1.2 :valid and :invalid

I think these pseudo-class names are unfortunate, as they suggest alternative meanings to their specific use with form controls.

For example, *:valid seems to suggest "all valid elements", but in fact it means elements that represent form controls whose contents are currently valid. It might be prudent in the long run to avoid such name collisions by using :form(valid) or some other mechanism.

This seems more relevant given the CSS3 Selectors candidate recommendation which introduces so many structural pseudo-classes that truly do apply to the *element* itself, such as :root, :nth-child, :empty, etc.

If a new pseudo-class was introduced to match empty form controls, such as text boxes with no content, calling it :empty would clash, while calling it :form(empty) would not, as well as being more descriptive.

(I have raised this point in the past regarding :visited / :link(visited), but that example is already too entrenched to remove).

automatic icons

1. Automatic icons

Specific Reference:

http://www.w3.org/TR/css3-ui/#box-model

The document introduces the new 'icon' value for the 'display' property of an element and adds an 'icon' property which identifies a resource which replaces the element in the rendered content if the the value of 'display' is 'icon.'

However, it goes on to include an 'auto' value for the 'icon' property which is "as defined by the user agent."

when one icon vs. another

But there is no clue as to when the user agent will use one icon vs. another.

Does this not open wide a barn door for entire UIs to be constructed without the faintest semantic clue in the 'content' as to what is going on?

no standard taxonomy of icons

The standing problem with the "separation of content and presentation" afforded by CSS is that there is no standardization of the 'class' tokens that govern the selection of style rules. This innovation perpetuates or exacerbates that problem, in that there is no basis in any standard taxonomy for the selection of UA-supplied icons.

icon use cases

Delivery contexts where we would be interested in the re-binding of elements where the author's presentation used display:icon and icon:auto would include:

Simplified verb vocabularies, for severe learning disabled -adaptive presentation as described in

http://www.learningdisabilities.org.uk/html/content/webdesign.cfm

a similar verb-vocabulary-reduction transform for operability from a telephone or computer number keypad. Used in mobile device transform and for users with good fine motor control but bad gross motor strength.

Personalized verb-vocabulary-transformation for auxiliary communication device uses with a large but personal vocabulary of one-button utterances.

Anyone else with high cost of input symbol actuation needing a normalization of the verb vocabulary as part of optimizing the binding of shortcuts.

don't put hyperlinks in focus navigation

2. Directional [focus] navigation introducing hyperlinks? Don't.

directional focus navigation is content?

Specific Reference:

http://www.w3.org/TR/css3-ui/#nav-dir

The specification introduces a mechanism by which a stylesheet can identify multiple navigation destinations (hyperlink equivalents) bound to an element in the document which are navigated-to and given focus on receipt of directional-navigation user-input events.

Each navigation destination may be an arbitrary URI-reference i.e. off the current web page, and the back button is by [the draft] specification broken.

This functionality should not be included as drafted here. Navigation destinations associated with an element are content, not style.

multiple/selectable hyperlinks proposal

The equivalent functionality should be implemented by

a) in the content, creating vectored, that is to say multiple/selectable hyperlinks using the results of the currently-active consultation on linking.

directional-navigation UI events for directional navigation?

b) in the styling, binding arrow keys or other directional-navigation UI events to these navigation arcs using the keyboard-control facilities established in section 8.2 above.

key-equivalent problems

4. Navindex and keyboard control:

For languages where an accesskey or similar function exists, the accesskey 
attribute should take precedence. It may be years before CSS figures into 
the interaction between sites and assistive technologies.

Key equivalents and nav-index items should also be displayable via menu, to 
allow users to discover them.

For the purposes of re-mapping, the user agent implementation of key 
equivalents and the navigation index ordering should be treated like event 
handlers as discussed in

http://www.w3.org/TR/UAAG10/guidelines.html#tech-device-independent-handlers

In the case of re-mapping because an indicated key is not available in the
delivery context, it is not enough to 'ignore' the indicated key.  *Some*
alternative mode of activation needs to be provided.  The provisions as
stated in XForms on this point should apply, here.

<quote
cite="http://www.w3.org/TR/xforms/slice8.html#id2623376">

  accesskey
         Optional attribute defines a shortcut for moving the input
         focus directly to a particular form control. The value of
         this is typically a single character which when pressed
         together with a platform specific modifier key (e.g., the alt
         key) results in the focus being set to this form control.

         The user agent must provide a means of identifying the
         accesskeys that can be used in a presentation. This may be
         accomplished in different ways by different implementations,
         for example through direct interaction with the application or
         via the user's guide. The accesskey requested by the author
         might not be made available by the player (for example it may
         not exist on the device used, or it may be used by the player
         itself). Therefore the user agent should make the specified key
         available, but may map the accesskey to a different interaction
         behavior.

 </quote>

system font and user prefs interactions

5. System fonts and colors:

If a user has extra large system fonts set at the OS level, and has their browser set to increase the size of Web sites by 200%, this could be a problem, in that the resulting font could become absurdly large.

small text with large icons, then large text?

At the same time, some users with low vision keep their icons small, but want larger text when they are reading rather than interacting with the OS. This is a thorny issue due to the juxtaposition of operating system and user agent accessibility conventions.

user should be able to override system appearance

Users should be able to override system font or appearance selections with their own choices or proportions, within the user agent.

compare with UAAG

Compare with the requirements in the User Agent Accessibility Guidelines such as

http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-styles

xforms terminology consistency

[individual comment, not reviewed in PF group.]

General Reference:

http://www.w3.org/TR/css3-ui/

1. :out-of-range

In

3.1.3. :in-range and :out-of-range
http://www.w3.org/TR/css3-ui/#pseudo-range

there appears to be a mis-use of XForms terminology.

Where it says

<quote
cite="http://www.w3.org/TR/css3-ui/#pseudo-range">

  v... In summary: an element is
  :out-of-range when it does not accurately reflect the state of the
  model.

</quote>

..should it not say "the state of the instance"?  Suggest you cross-check 
with XForms.


A possible re-wording of the whole paragraph would be:

<draft class="possible clearer">

The :in-range and :out-of-range pseudo-classes are defined with respect to 
the limitations of the rendered or concrete interface, as opposed to the :valid
and :invalid pseudo-classes defined above which reflect the logical 
limitations imposed by the application or business logic through the model.

A rendered element is :out-of-range when the value in the bound instance that
it should display is beyond its capability to display.  For example, a slider
which can show values from 1-10 when the value in the instance is 11 would
have :out-of-range true and :in-range false.

</draft>

what is a form element

2. What's a form element?

<quote
cite="http://www.w3.org/TR/css3-ui/#pseudo-required-value">

   3.1.4. :required and :optional

  A form element is :required or :optional if a value for it is,
  respectively, required or optional before the form it belongs to is
  submitted. Elements that are not form elements are neither required
  nor optional. This spec does not defined what is a form element.

</quote>

The last two sentences taken together form a semantic hole in the 
specification.  This will lead to semantically-incompatible use by 
different users and implementers and the feature will become disreputable 
and will be avoided in practice.  Unsuitable in a specification.

Consider instead:

Cite specifically the items in the XForms schema and HTML specification
which have the intended semantics, and extrapolate gracefully from there.

Say things like

processors MUST recognize the following conditions as :required and 
:optional
where the XForms schema applies:...

processors MUST recognize the following conditions as :required and 
:optional where HTML 4.01 semantics applies by specification:...

processors MAY recognize these pseudo-classes in formats which use clearly
equivalent semantics

processors SHOULD NOT recognize either :required or :optional in the absence of
any of these conditions.

many editorial suggestions

Hello,

These are very minor Last Call comments for your "CSS3 Basic User
Interface Module" Working Draft [1]. I think it looks nice.

In the Status section, please match caps to the W3C Process Document [2]
(e.g., s/working group/Working Group/, s/working draft/Working Draft/,
s/style activity/Style Activity/). Also the CSS21 link would be
http://www.w3.org/TR/CSS21/

When HTML 4 comes up, you might add XHTML 1.0.

s/This spec does not defined/This spec does not define/
s/which portion of a the contents/which portion of the contents/
s/all the elements contents/all the element's contents/
s/it and the platform is capable/it and the platform are capable/
s/recommendation/Recommendation/

External links need a reference like this for people who print:
    HTML4 attribute TABINDEX
becomes:
    HTML4 attribute 'tabindex' ([HTML4], section 17.11.1)
(see http://www.w3.org/2001/06/manual/#linking-within)

In citations, the title of the work would be the link. There's an
example here: http://www.w3.org/2001/06/manual/#ref-section

This sentence:
    The <uri> should indicate (through the use of a fragment
    identifier) the element to which the focus is to be navigated to in
    response to directional navigation input respective to the specific
    property.
could read (I think. You can probably do better.):
    In response to directional navigation input, the <uri> should
    indicate the element to navigate to through the use of a fragment
    identifier.

Please spell out first occurrence: user agent (UA). Then you can use
UA. Or else use user agent throughout.

It would take some work to do but it might help if each occurrence of a
property, element and attribute was marked up in lowercase 'code'. (I
think this will help translators decide when to translate for example
'icon', and it might make the spec easier to read in English.) Some
specs also differentiate properties from elements from attributes with
color.

[1] http://www.w3.org/TR/2003/WD-css3-ui-20030703/
[2] http://www.w3.org/2003/06/Process-20030618/

i18n issues with CSS3-UI

Apologies for lateness.

Please find the comments of the I18N group at http://www.w3.org/International/2003/css3basicui/css3basicui-feedback.html

We hope this proves useful.

CSS modularity is new to W3C

Hi, I have made the review of CSS3-UI, which is a modular spec. The technology becomes more and more modular with time. It has an influence on the way WGs organize their Spec editing. We have moved from a monolithic spec to a multiple document spec.

CSS3 is multi-spec

The last big monolithic spec have been SMIL and SVG, even if organized in modules.

Often in this reorganization, you have a master document which defines conformance, usage scenarios, etc. and the modules attached to it.

For example CSS has moved from a 1-spec (css1 and css2) to a multi-spec (css3).

1 REC = 1 Tech is no longer the case

This way of writing specifications raises a very important questions on the notion of 1 Recommendation = 1 Technology. It's not anymore the case.

W3C missing concept of building block definition

1. Should a technology be considered complete when all the bricks are ready. So is there a missing concept inside W3C which defines this set of bricks?

should a CSS3 WD reach REC before others?

2. Should a WD (which is a module of this set) be authorized to reach the status of Rec (and even Last Call without the other bricks)?

how define dependencies?

2.1 If a module can become a Rec without other elements of the set - How do we define depencies?

usage scenarios?

- How do we create usage scenarios? etc

conformance section?

AND more important ***How do we apply QA Spec Guidelines?*** There's a big issue here. We can't for example find the conformance section because sometimes it's in a document which is not written yet.

additional process mechanism?

2.2 If we think that a module can NOT become a Rec without others elements of the set. - How do we create the mechanism in the process document that specify this.

how is QA Spec Guidelines working?

- We have to check that QA Spec Guidelines is working well with modular docs Notion of table of contents, references, etc.

Question about Abstract

You have written “The ability to style the appearance of various standard form elements in HTML4 and properties to augment or replace some remaining stylistic attributes in HTML4.” Could it be misleading for developers that it doesn't address XHTML 1.0 or XHTML 1.1 or any future versions of XHTML?

How to read the comments in the table

We have decided to make a difference between negative answers when you do not comply. CSS3-UI is a module of a bigger set as you have written in the status section: “This document is a draft of one of the "modules" for the upcoming CSS3 specification.”. One issue is to establish if you do conform to the QA Specification Guidelines. It is impossible if we consider only this specification. It might be a QA issue. A mail will be sent to www-qa@w3.org

It raises the question if a WD of a modular set can reach the status of W3C Recommendation if other parts are still at another stage.

how do apply QA Spec Guidelines

If yes, it means that the QA Spec Guidelines have an issue making it impossible to apply.

If no, it means that the CSS WG will have to define the master document which defines the missing part before to go to final stage.

respond to "NO" squares

So There will be a lowercase no when it's dependent on the master specification and a uppercase NO with red background when it's an issue of this module only.

Checklist table

Degree A Conformance

To be A-conformant with the guidelines, the following Priority 1 checkpoints must be fulfilled: Nbr Checkpoint Yes No N/A Guideline 1. Define Scope.

1.1 Include the scope of the specification. YES

Guideline 2. Identify what needs to conform and how.

2.1 Identify all classes of product. no: there's no mention of the products which should implement it. You do not define also what's an UA. No glossary for this acronym.

conformance

For each class of product, define the conformance requirements. no: See General comments. Guideline 3. Specify conformance policy.

3.4 special terms

If special conformance terms are used, include a definition in the specification. no: See General comments.

3.5 dimension of variability

Justify any usage of a dimension of variability by reference to usage scenarios and requirements no: See General comments.

Guideline 4. Address the use of profiles to divide the technology

4.1 Indicate whether or not the use of profiles is mandatory for conformance. no: See General comments.

Guideline 5. Address the use of modules to divide the technology.

5.1 If modules are chosen, indicate any mandatory conditions or constraints on their usage. no: See General comments.

Guideline 7. Identify the relation between deprecated features and conformance.

7.1 Identify each deprecated feature. NO: this is a very tricky case. It's not exactly a deprecated feature but a redefinition of another technology behaviour. How people are supposed to implement them. How User Agents should implement HTML 4.01 with CSS3-UI when the two compete? N/A

Guideline 7. Identify the relation between deprecated features and conformance.

7.2 For each class of product, specify the degree of support required for each deprecated feature and the conformance consequences of the deprecation. N/A

Guideline 8. Define discretionary items.

8.1 State the circumstances for when discretionary items are allowed no: See General comments. it seems that any features could be discretionary. It's dependant of your notion of profiles, in this case but you haven't defined the profiles.

8.2 allowable diffrences.

For implementation dependencies, address the allowable differences between implementations YES

Guideline 9. Allow extensions or NOT!

9.1 Indicate if the specification is extensible. NO: You should define if the extension are allowed or not. State it.

9.2 If extensions are allowed, define their scope and constraints. N/A: just because we don't know if the specification is extensible or not.

9.3 Prevent extensions from contradicting the specification. N/A: just because we don't know if the specification is extensible or not.

Guideline 10. Provide a conformance clause.

10.1 Include a conformance section. no: See General comments. You didn't provide any conformance clause. You have to give one explaining how the different classes of products should conform to your specification. Make a reference to the conformance section in this spec to the one where it will be defined.

Guideline 11. Specify how to make conformance claims.

11.1 Identify and define all conformance designations. N/A: Only because you don't have any conformance sections.

11.4 impose no restrictions on reports.

11.4 Impose no restrictions about who can make a claim or where claims can be published. N/A: No conformance section.

Guideline 13. Clearly identify conformance requirements.

13.1 Use conformance key words. no: See General comments.

13.2 Distinguish normative and informative text.

NO: You do not define the section of your documents which are normative. Please add after each section, a word to show that this part is normative, or that part is informative.

13.3 Use consistent terminology

YES: It seems correct. Define the terms which are not defined or acronyms.

Guideline 1. Define Scope

1.4 Provide examples. YES

Guideline 3. Specify conformance policy

3.1 Specify any universal requirements for minimum functionality. no: See General comments.

Guideline 4. Address the use of profiles to divide the technology.

4.2 If profiles are chosen, define any minimal requirements. no: See General comments. Profiles are chosen but we are unable to determine how they will work.

4.3 profile relationships/interaction

If profiles are chosen, define their relationships and interaction with other dimensions of variability. N/A. To be defined.

4.4 rules for profiles and implementations

If profiles are chosen, address rules for profiles. N/A. To be defined.

Guideline 5. Address the use of modules to divide the technology and Guideline 6.

5.2 If modules are chosen, define their relationships and interaction with other dimensions of variability. YES

Guideline 6. Address the use of functional levels to divide the technology.

6.1 If levels are used, define their relationships and interaction with other dimensions of variability. YES

Guideline 8. Define discretionary items.

8.3 Indicate any constraints on the number of choices/options that can be implemented for discretionary choices no: See General comments.

8.4 consistent handling of discretionary choices.

8.4 Promote consistent handling of discretionary choices. no: See General comments.

Guideline 10. Provide a conformance clause.

10.2 Make normative reference to specifications on which the current specification depends YES

Guideline 13. Clearly identify conformance requirements.

13.4 Provide a fast way to find conformance information no: See General comments.

Guideline 14. Provide test assertions.

14.1 Provide test assertions NO: You have a test suite, but you don't provide in this document a way to know what is testable.

14.2 Provide a mapping between the specification and the test assertions list NO: You don't have this list.

Degree AAA Conformance. Guideline 1. Define Scope.

1.3 Provide Usage Scenarios. NO

Degree AAA Conformance. Guideline 2. Identify what needs to conform and how.

2.3 Identify which of the categories of object are specified in the document as a whole. no: See General comments.

Degree AAA Conformance. Guideline 7. Identify the relation between deprecated features and conformance.

7.4 Include an explanation for the deprecation. NO: not always. (wrt HTML 4.01)

7.5 Include examples to illustrate how to avoid using deprecated features. NO

Guideline 9. Allow extensions or NOT!

9.4 Define a uniform mechanism to create an extension. NO

publish extensions and alterantives

9.5 Require that extensions be published. N/A. because not defined.

9.6 Require that implementations provide interoperable alternatives to extensions N/A. idem.

Guideline 11. Specify how to make conformance claims.

11.2 Provide specific wording of the claim. no: See General comments.

11.3 Provide a conformance disclaimer.

no: See General comments.

Guideline 12. Publish an Implementation Conformance Statement proforma.

12.1 Provide an Implementation Conformance Statement proforma. no: See General comments.

12.2 Require the ICS be completed as part of the conformance claim. no: See General comments.

could you add scrollbar-* properties?

Do you add Scrollbar Property like in MSIE scrollbar-*-color (for example: scrollbar-shadow-color: #DEE3E7; or scrollbar-face-color: #DEE3E7; ). I think it should be added because scrollbars are like cursor. There are a lot of scrollbars in forms and in other block with overflow: scroll

summaryOfComment

Hi,

My comments can be found at

http://lists.w3.org/Archives/Public/www-archive/2003Jul/0036.html

regards.