In a product with two colors, is it better to use two itemprop items or just one?
<meta itemprop="color" content="red" />
<meta itemprop="color" content="black" />
Or
<meta itemprop="color" content="red and black" />
I am using https://schema.org/ vocabulary.
From the Microdata perspective, both ways are possible. The difference is that you are adding two values in the first case, and one value in the second case.
From the Schema.org perspective, we’d have to understand how this property was meant to be used. The description of color says:
The color of the product.
It uses singular here, so this could be a hint for using your first example. But it uses "The color" and not "A color", which might suggest that they only thought of cases where a product has only one (primary) color.
I think it makes more sense to use several color properties. When using an own property for each value, consumers wouldn’t have to parse your string (possibly containing several colors) and trying to extract each color.
The only time I’d consider using one property containing several colors would be when I consider it to be "a new color containing other colors", so to say.
Oh, and just to be sure: Your markup would mean that one product is red and black, and not that you have the product available in red or in black.
Related
If h1 is considered a block, then does that make the spans elements of the h1 block? I guess, they are elements of the h1 block. What I want to know is, which one of the two codes is accurate? In the first one, I used underscores, and in the second one, I used dashes. Which one is accurate?
<h1 class="heading">
<span class="heading__main">physics</span>
<span class="heading__sub">the mother of all sciences</span>
</h1>
<h1 class="heading">
<span class="heading--main">physics</span>
<span class="heading--sub">the mother of all sciences</span>
</h1>
NOTE: Do not answer if you don't know BEM. I am telling this because the above terminology resembles very much with basic HTML and CSS.
Up front:
From a BEM point of view it is irrelevant whether an html element in a block has semantic meaning (like H[1...6], P, ARTICLE, SECTION etc.) or is meaningless like SPAN or DIV. BEM is concerned with organizing the presentation not with organizing html structure. BTW, you could make SPAN a block element or DIV an inline element with the respective display-definition in your BEM-class. None of this matters when it comes to BEM.
Let's get to the core of your question.
I challenge the answer of Himanshu Saxena.
If you have a block class named
heading
then if you are using a modifier on that very class like
heading--main
the BEM semantic expresses that you are modifying that very block, which in your case is the h1 tag.
If you apply the block's class modifier on a tag other than the tag to which the block class is applied, it's a contradictory information you send to the reader of your code.
So, your first code example is accurate because it clearly states, that
heading
is your block. All potential modifiers on heading should be applied to the tag which contains the heading block class. That's the only location that that class' modifier belongs to.
If you indeed had a modifier like
heading--main
you'd have to to apply it to your h1 tag, because your bem expression semantically reads: "I am modifying the rendering of heading by applying the class heading--main".
You can't (of course you can, but then it's not BEM anymore) apply the heading's modifier to another tag, which does not bear the heading tag.
The classes
heading__main
heading__sub
clearly express that there is structural relationship between heading and main and that heading__main refers to an element somewhat below heading.
Bear in mind, that the BEM structure does not need to reflect the HTML structure.
Another important aspect of BEM is that the block should be in control of the location and the size of its enclosed elements.
In order to allow this you need to have an element class.
The only modifiers BEM allows on elements are the elements' modifiers but never ever its surrounding block's modifiers.
I hope, it wasn't too confusing. In any case stick with your first example, it's definitely the right one.
From the above example you shared the Modifier looks appropriate.
Since its still debatable to be an element or a modifier. Below are my observation.
Since both the span are coming under same h1 tag they can be considered as element of H1 since as per the name's main and sub these are two different types and, when we talk about types of a block which means we are changing the state.
When there is a state change, it should be considered as a modifier.
Hence for me modifier looks more suitable than an element.
I want to allow authors to enter long descriptions in the CKEditor image plug-in dialog, descriptions which then are available to screen readers via the aria-describedby attribute. In our use case, authors work in a WYSIWYG mode; they're not expected to edit raw HTML, so we can't ask them to enter an ID in the image dialog, add a corresponding ID to some other element, etc.
It's a trivial matter to enhance the CKEditor image plug-in dialog to have a field where the author can enter a long description to accompany the short alt description. The result could be something like <img data-long-description="this is a long description" alt="short description" />. But what we need is <img aria-describedby="longDescriptionID" alt="short description" />, where longDescriptionID is the ID of some element on the page (hidden from sighted users or not)....
I have a couple of possibilities in mind. (1) keep the image plug-in doing what it does: output an <img /> tag, as in the first example, and then some other code in the end user-facing view has the responsibility to find data-long-descriptions, replace them with IDs (randomly generated, say) in an aria-describedby attribute, and somewhere in the view insert corresponding content hidden from visual users, so that screen readers will pick it up.
Possibility (2) is to have the image plug-in output something like <span class="accessibleImage"><img aria-describedby="randomID1" alt="short description" /><span id="randomID1" class="accessibleLongDescription">This is nice, long description of the image blah blah blah</span></span>, where .accessibleLongDescription is hidden except to screen readers.
It's good that you're looking into this. More detailed descriptions for images are often useful. A couple of thoughts...
It isn't just people who use screen readers that find longer descriptions useful. People with cognitive disabilities will often benefit from more detailed explanations of complex images. If you can make the descriptions available on demand to anyone, this will help more people.
When the description is inserted into the DOM it needs to be immediately after the image it relates to. Screen readers use a translation of the DOM known as the accessibility tree to access content, so DOM order is important.
So one possibility is to combine your methods - search/replace the data attribute as you suggest in your first method, then insert the description based on the pattern in your second method.
Another possibility might be to use a disclosure widget pattern instead. Represent the image as the trigger control for the disclosure, and make the detailed description available when the widget is expanded.
A reasonable disclosure widget pattern is here.
(I'm interested in HTML 4.01 and HTML5, if there should be differences)
Does the lang attribute on an img element apply to the src attribute, too? Or is it only for the alt and title attributes?
Example:
<img src="example.png" alt="a red foobar" lang="en" />
Is the image "example.png" considered to be in English? (think of screenshots of a forum thread, or a graphical representation of a word, or a scan of a document)
If it's true, images with non-linguistic content would need to get lang="zxx". But that would apply to the alt/title attributes, too, which would be incorrect.
HTML 4.01 defines the lang attribute as specifying “the base language of an element's attribute values and text content”, whereas HTML5 defines it as “the primary language for the element's contents and for any of the element's attributes that contain text”. The difference is apparently in the formulation only. The lang attribute specifies the language of alt and title attribute as well as other attributes that may contain prose text, as opposite to code-like values like URLs or style attributes, where (human) language is not applicable.
The src attribute itself is not of any (human) language, logically. So the question is whether the lang attribute extends to the image denoted by the src attribute. This is a fairly theoretical question – what impact on software behavior could the answer possibly have? Anyway, the answer depends on what we understand as “text content” (images are text in a sense, in formatting, but probably HTML 4.01 means to refer to actual character data only) and as “element’s contents” (is an image part of the img element’s contents?). Overall, it seems that the language of the image (though a feasible concept) cannot be specified in HTML.
So there is no need to worry about images with non-linguistic content. For text content that is “non-linguistic” (i.e. not text in any human language but e.g. some code notation, or a random sequence of character), using lang="" is what HTML5 recommends. It’s also the practical approach. In the few cases whete lang attribute has any impact, as in automatic hyphenation, lang="" effectively means that no language rules are applied (e.g., no hyphenation). This is different from omitting the attribute, which means that the element inherits language information from its parent.
In HTML 4.01, section 13.8 says:
The language of the alternate text is specified by the lang attribute.
In HTML5, it says:
Specifies the primary language for the contents of the element and for any of the element’s attributes that contain text.
I can't find anything in the current HTML5 draft that defines the relationship between the alt and lang attributes as explicitly as the HTML 4.01 spec does. Hopefully it'll be clarified later, but I would assume for now that there isn't any change, and that what it does state is just as applicable.
Neither spec states an explicit relationship between the src and lang attributes, but I wouldn't assume that the language of the source image itself corresponds to the lang attribute, since not all images will have linguistic content (as you've mentioned).
The same goes for title and lang, but this may depend on the element type, I'm not entirely sure. Again, what it does state in general above should be applicable to title.
I am just starting with jquery.validation and like it. One reference I felt specifically helpful when trying to understand the big picture is http://docs.jquery.com/Plugins/Validation/Reference#Markup_recommendations. One part I didn't understand is why labels need to be associated with each input. Yes, I understand that labels are created to display error hints, however, these are different labels. I couldn't detect any change on the label tag, and it works fine without it. Anyone know why? Thanks
Each input has a label associated with it: The for-attribute of the label refers to the id-attribute of the input.
<label for="firstname">Firstname</label><input id="firstname" name="fname" />
In this case labelis actually HTML element that adds usability improvement for mouse users where if user clicks on the text within the element, it toggles the control.
In HTML label is an optional element, That means you don't need to provide label for each input
I don't find the oft-used "*" to be very nice looking - can anyone suggest a nicer-looking method or point me to an example?
I tried making the field highlighted in red as one person suggested but I did not like the look.
Bold labels might do the trick.
But I really like the idea of "Required" being shown in grey in the field until text is added. Does anyone have code for this?
Generally speaking, the best web forms are the simplest ones that require me to think the least. The "standard" that has evolved is that required fields have an asterisk (*) next to them. Sometimes the asterisk is red to help it stand out a bit.
Why fight the standard? Don't make your users think too much. Go with the standard and keep your creativity for more important things.
If you're going to use colour to highlight the field, bear in mind that some people are colour-blind (so maybe provide another indicator too)
If you use stylesheets to format your HTML, then you can create a style for .mandatory. As an example, set the mandatory input to use this style, then you can play with it more easily until you have the right mix of color, border, and other style elements to suit your overall design.
HTML
<input id="username" type="text" class="mandatory" />
CSS
.mandatory {
color: red;
font-size: 12pt;
font-weight: bold;
font-style: italic;
}
I also use the asterisk as the OP mentioned as a "backup".
-R
Sometimes it really is justifiable to mark fields as mandatory and optional. However, before you do so, you should question whether it is reasonable to ask the user any non-mandatory information. This applies especially in registration forms.
In registration forms and such, it is much better to ask only the minimum information. After the registration the user can, at will, fill out optional information in separate forms.
After all the unnecessary cruft has been taken out from the form, you might see that there is no need to mark fields as mandatory; either everything is mandatory, or it might be so obvious to the user which fields are optional, that there would be no need to give visual cues about it.
add style="border: thin red solid;" to the element
I've found the answers on LukeW.com to be the most useful. because there isn't a simple solution here. It depends on what percentage of the fields are required, how many fields are in your form, and how long your labels are. For the vast majority of the web, people understand bold to be required, and normal-weight to be optional (if any options are bolded). Only after form validation fails would I present the user with the required-yet-skipped input boxes highlighted.
I typically have no objections to seeing (required) in a smaller font either right below the field name or adjacent to the entry field.
I could also see using a "textbox watermark" to have the field say "required" in it until they bring focus to the field and start typing.
I like the way it is done in the ASP.NET Ajax Control Toolkit for the ValidatorCallout control:
Might want to check out www.PeterBlum.com - His Professional Validation Package rocks for validating and formatting of controls. He has tutorials for using and numerous examples as well as a detailed manual.