Can I use this (custom elements, custom attributes) on (for examples) IE 9 with this CSS? Is this valid? What are the negatives?
I want to have more readable code... without divs.
HTML
<row center>
<column number="6">A</column>
</row>
CSS / LESS
row {
background: #444;
display: flex;
&[center] {
justify-content: center;
}
column {
background: #222;
color: #fff;
&[number="6"] {
padding: 1rem;
width: 50%;
}
}
}
The case against custom elements has been made by other answers. As an alternative to this idea, HTML 5 has a number of new elements. These include <article>, <aside>, <figure>, <header>, <nav>, and <section>. Using these elements should make your page layout semantically meaningful, save you from puzzling over a sea of <div> and <span> elements, and be understood by modern browsers.
Making up your own markup language:
May conflict with additional features added to HTML in the future (at least if you tell the browser it is HTML with a Content-Type: text/html HTTP header).
Won't be properly understood by user agents which you can't completely override with CSS (such as screen readers, text browsers and search engines).
Won't be understood by other developers who may have to maintain your code in the future.
Can't use an HTML validator for a cheap, basic QA pass
The W3C is developing a standard call Custom Elements, which allows authors to define their own elements. You can read about it here:
Custom Elements, defining new elements in HTML
Custom Elements allow web developers to define new types of HTML
elements. The spec is one of several new API primitives landing under
the Web Components umbrella, but it's quite possibly the most
important. Web Components don't exist without the features unlocked by
custom elements:
Define new HTML/DOM elements
Create elements that extend from other elements
Logically bundle together custom functionality into a single tag
Extend the API of existing DOM elements
Introduction to Custom Elements
Custom Elements enable developers to create their own custom HTML
tags, let them use those tags in their sites and apps, and enable
easier component reuse.
W3C Custom Elements
Provide a way for Web developers to build their own, fully-featured
DOM elements. Though it was long possible to create DOM elements with
any tag names in HTML, these elements weren't very functional. By
giving Web developers the means to both inform the parser on how to
properly construct an element and to react to lifecycle changes of an
element, the specification eliminates the need for
DOM-as-a-render-view scaffolding that has to exist today in most web
frameworks or libraries.
However, if your goal for today is to write more readable code, then consider sticking with standard HTML elements (or just div and span elements) and using class and id values for descriptions. You can be as descriptive as you like with classes and ids. See my answers here for guidance:
Default settings of unrecognized HTML elements
Is there a standard method for naming classes?
HTML5 ID Attribute Values
Related
Doing a code review, I noticed that a heading was using <span> tags instead of headings, so I suggested using an <h4> tag, to gain the semantic benefits. The context is a website footer, where there are various lists of links under different headings.
<span>Category 1 Links</span>
<ul>
<li>Link 1 in the footer</li>
<li>Link 2 in the footer</li>
<li>Link 3 in the footer</li>
<li>Link 4 in the footer</li>
<li>Link 5 in the footer</li>
</ul>
The counterargument was that <h4> is a "block-level" element, whereas an inline element was needed. Therefore he didn't think the element should be changed. (And yes, he knows CSS and is familiar with the display: inline; property.)
That sounds absolutely insane to me--goes against everything I always thought was best practice: separation of content and presentation, semantic web, the very purposes of HTML and CSS... yet in trying to formulate a response, I came across this section in the HTML 4.01 spec:
Certain HTML elements that may appear in BODY are said to be
"block-level" while others are "inline" (also known as "text level").
...
Style sheets provide the means to specify the rendering of arbitrary
elements, including whether an element is rendered as block or inline.
In some cases, such as an inline style for list elements, this may be
appropriate, but generally speaking, authors are discouraged from
overriding the conventional interpretation of HTML elements in this
way.
The alteration of the traditional presentation idioms for block level
and inline elements also has an impact on the bidirectional text
algorithm. See the section on the effect of style sheets on
bidirectionality for more information.
So here is the question: does this section make the issue sufficiently vague for there to be valid difference of opinion here, or is it (as I had thought) pretty clear in one way or the other? If this section is open to interpretation, are there any other W3C guidelines that are more concrete?
I don't want to get into opinions on this, I just want to make sure I'm understanding the spec and the W3C guidelines correctly: is there true ambiguity here, or not?
W3C specifications allow display: inline on heading elements. In general, HTML specifications do not restrict what you can do in CSS, and vice versa.
The section Block-level and inline elements that you quoted contains a recommendation (“discouraged”). It is a “should not”, not a “shall not” statement, i.e. not a conformance criterion. The motivation for the recommendation is not given, but generally such ideas are based on the fact that HTML documents may be processed by software that ignores style sheets, or may have author style sheets overridden, or otherwise gives preference to the defined meanings of elements rather than their CSS styling.
Even though the possibility of making a heading an inline element (in the sense of setting display: inline) is not mentioned here, doing so is part of one way of creating “run-in headings” (headings that appear inline at the start of a paragraph, rather than on a line of its own). Nowdays a better way to achieve that is display: run-in, as exemplified in the CSS basic box model WD. The basic point is still the same: it’s OK to turn a heading element from its default display: block to inline-like presentation.
Regarding the specific case presented, I don’t quite see why an inline element would be needed. The next element is ul, causing a line break (and vertical spacing) by default. And if the rendering of the ul is changed to inline with CSS, it is difficult to see why you could not do the same to an element that is logically a heading for the list.
First of all, the quoted section is indeed from the 14-year old HTML 4.01 specification. I do not remember ever reading anything of the type in the HTML5 specs. I personally think it was deemed a good remark at the time but has since been obsoleted by experience. Don't forget that HTML4 was the one to actually properly separate HTML and CSS, and as such contains 'mistakes' like the quoted remark that were later 'corrected'.
In essence, there should not be any implicitly locked relationship between your semantic markup and your styling. Like the hX elements, a div is also a block level element, but only because of the way it interacts with other elements, most specifically which elements it can contain - an inline element must not contain a block element while a block element can contain both inline and block elements, bar explicitly defined relationships such as ul > li and table > tr > td. Essentially the separation of semantics and presentation should be kept so strict that the specifications of the markup language HTML should never even mention the existence of the concept of stylesheets - stylesheets can be applied to anything, not just HTML, and HTML feeds so many more technologies than just browsers.
From a web developer's perspective, you are absolutely right. The block nature of a h4 element merely implies its relationship with potential child elements, and its default representation in the browser's default stylesheet. What the CSS developer then wants to do with his stylesheet is his own choice - for all you care he applies a display:table-cell rule to it if that properly fits his design.
TL;DR: There is no ambiguity, and you should always write your CSS to conform to how you want to display your HTML, not adapt your HTML to the requirements of the CSS. Using a span where an h4 is required is just plain wrong from a semantic (and SEO) perspective.
In my opinion, any typographic convention that you have ever seen in a book or other printed media is fair game for modeling a web page.
For example, I have seen text books with several columns, each with a header, and one could achieve this effect by using display: inline to a h4 tag.
In this example, whether h4 is on a stand-along block or part of a horizontal sequence will depend on the content and how you are trying to communicate ideas to your readers.
Consider how your page would render in a text-only browser that does not support CSS, would the raw ordering of the text make any sense? If so, then, your choice of HTML are probably valid.
On the other hand, if you took table tags and turned them into headers or list items, then you are probably going to get HTML that would not sound right if the page were read by some type of audio browser (think visually impaired people using a page reader).
Let semantics dictate the tags that you use and use CSS to get the visual layout that you need.
I've read that it's bad practice to style content based on HTML5 data-* attributes.
Quote from html5doctor.com:
The presence/absence of a particular data attribute should not be used
as a CSS hook for any styling. Doing so would suggest that the data
you are storing is of immediate importance to the user and should be
marked up in a more semantic and accessible manner.
Could someone shed some more light on this statement or give some examples of why this might negatively impact a user's experience?
As a really basic example, say I'm using data-attribute-error="404" on elements to give feedback to a script, instead of having to also add error-404, error-500, etc classes on each element for some supplementary styling, couldn't I just style these like so:
.error { color: red; }
.error[data-attribute-error]:after { content: attr(data-attribute-error); }
.error[data-attribute-error=404] { color: grey; }
.error[data-attribute-error=404]:after { color: red; }
/* etc */
This probably isn't the best example, and I'm not worried about browser support. I'm just trying to understand the overall concept better.
Seems there would be a lot of cool stuff we could do with CSS3 and custom attributes to style things based on content, keeping our 'real' classes more general to handle pure styling that isn't based on content.
Is this just a general guideline that can be ignored in certain situations, or is it a horrible client-side sin?
Thanks!
Basically what they're suggesting is that if the error message, status or number is important enough to present to users then it should be presented in an accessible way. WCAG Guideline 1.4.1 says:
Use of Color: Color is not used as the only visual means of conveying
information, indicating an action, prompting a response, or
distinguishing a visual element. (Level A)
The other thing to note is content created by CSS is not available to screen readers and other assistive technologies.
I have not worked extensively on Client Side/Front End of the Application and I am trying to read about HTML, CSS and DOM but somehow am not able to figure out difference between them and so would really appreciate if someone can:
Explain me in simple English how does HTML, CSS and DOM work ?
How do they relate to each other from Client Side Technology point of view ?
Update
I have gone through wikipedia articles but not able to clearly understand working of DOM.
Thanks.
What is the DOM?
Let's say you open a web browser (e.g. Chrome) and load a web page in it (e.g. stackoverflow.com). Now, inside the browser, there is an window object. This object represents the browser window.
This window object has dozens of properties (members), the most important of them being the document object. The document object represents the web page that is currently loaded into the browser window.
This document object is the root of the DOM tree:
(source: w3schools.com)
Each box in the above picture is a node inside the DOM tree. A node is an object that is "connected" to other objects from the DOM tree.
The JavaScript programs that are bound to a web page have complete access to every node of the DOM tree. They can delete nodes, add new nodes, or just manipulate the properties of a node.
To sum up, inside the browser there exist hundreds of objects. All these objects are connected (somehow), and this huge structure of inter-connected objects is the DOM.
HTML is what is on your website (headings, lists, tables)
CSS is what those things look like (borders, colours, font sizes)
DOM is how you access those things through javascript (getting nodes, adding new elements, changing their style)
Here is an example of the 3 working together (doesn't seem to work in ie)
http://jsfiddle.net/gj9zT/
HTML describes the structure of a document. The browser parses HTML and constructs an internal representation of the elements of the document from it, like:
document
|
|-body
|
|-div
| |
| |-p
| |
| |-"some text"
|-div
|
|-...
This internal representation is the DOM, the Document Object Model. This is the basis for creating the actual visual representation of the website.
CSS is used to define how this visual representation looks exactly.
Parts of the DOM are also exposed through an API, so you can manipulate the DOM (i.e. the document) using a programming language like Javascript.
Have a look at
Confused by relation between DOM and HTML (APIs)
Difference between html and dom
Its a long explaination but i will try to explain in brief
CSS: These are used to apply property's to html elements. If you want to apply a common color to various html elements we can do it in css and apply that class to html element. We can avoid repeatation of code with css.
We can achieve many other things with css. Read in google
HTML: HTML is nothing but various kind of tags we use to display the elements like tables , divs , p , ul , li etc
DOM: DOM is nothing but the relation between the html elements , we use javascript normally to manipulate the DOM like changing height , moving from one place to another...
There will be lot of links in google , you can better explanations.
HTML (HyperText Markup Language) is the markup we use to describe the structure of our page. It defines the different constructs like <ol></ol> Ordered List or <table> Tables etc...
HTML is the code we start with, it's human readable (well it's supposed to be anyway :p) and easily compressable & transferable.
DOM (Document Object Model) is the framework your computer uses to organize the page it renders from HTML. When your computer breaks down your HTML Document it organizes it into an Object Model which it can more easily work with (and so can you, in javascript/css/etc...).
CSS (Cascading Style Sheets) describe how you want items in your documents to look. They're named cascading style sheets because they "cascade" down to the next one to fill in the holes or override styling. CSS describes the visual qualities of the objects in the DOM.
HTML is effectively the markup of your DOM (Document Object Model). The root of the document is <html>, which contains many levels of <div>s, <p>aragraphs, <h1>eaders and so on.
The DOM is the tree (graphical structure) of your html markup. It will have a 'root', which has many 'children', the children will have 'siblings' and 'parents', 'descendants' and 'ancestors'. The root doesn't have a parent, and is an ancestor of all the descendant nodes. for instance, your typical html document will be structured like this:
<!DOCTYPE html>
<html>
<head>
<title>Banner Example</title>
<style type="text/css">
#header {
background-image: url('branding_logo.jpg');
}
h1 a {
display: block;
height: 120px;
width: 500px;
text-indent: -9999; /* to hide the text that would show */
/* over the banner */
border: 1px solid black;
}
</style>
</head>
<body>
<div id='header'>
<h1>This is a header link.</h1>
<p>Here is some text.</p><p>Here is some more text.</p>
</div>
<div id="content">
<p>here is a bunch of content.</p>
</div>
</body>
</html>
In this case, html is the root node, which has two children: head and body. Head and body are siblings. You can use the DOM model with selectors in order to select which objects (contained in a node) will be affected by code such as CSS.
CSS will take selectors and style them as you specify in its attribute block. You could select all elements <p>, using
p { color: red; }
Or you could select only 'p' where it's a descendant of a div whose id is content:
div#content { color: black; }
CSS will typically style a tag using the most specific DOM description that can be applied to it. So, in my above html example, the first css style will apply to all p, and then the second, more specific styling will be applied to only that one p in the content div.
Essentially, what happens is your browser will parse your HTML code into sections that allow them to be selected individually. That parsed structure is your DOM. CSS uses the DOM to apply styles. jQuery does the same, allowing you to select a specific node from the DOM and apply styles or actions to that node dynamically on the client side.
I'm new to HTML. When I started reading documentation about lists, I've noticed that everywhere an <ul>, <li> structure is used, even for creating very simple lists.
But for me it's most comfortable to use only <a> elements with CSS:
display: block;
/* and/or */
float: left;
So, why use <ul>, <li> instead of just <a>?
Thanks a lot.
Because structurally they're the most appropriate elements for that purpose. Also helps screen reader users in terms of properly dictating the elements of a page.
Remember that HTML is for markup/content ( what IS this text? a paragraph? wrap it in a p tag ), CSS is for styling, JS is for behaviour.
You can have thousands of anchors on your web page, but what if you want to style anchors nested within listed items differently from other anchors?
<ul>
<li>blah</li>
</ul>
sfl
If you had done things properly, your css would be trivial to implement
a { }
ul li a { }
Otherwise you'd have to throw classes around anchors and it would be messy and unstructural.
In regards to the SEO - I believe that in the past semantically marked up code didn't have much bearing but nowadays with specs like RDF, HTML 5 elements the web is getting more and more semantic, so it's only beneficial to be as semantic as you can be.
In 2010, Google specified three forms
of structured metadata that their
systems will use to find structured
semantic content within webpages. Such
information, when related to reviews,
people profiles, business listings,
and events will be used by Google to
enhance the 'snippet', or short piece
of quoted text that is shown when the
page appears in search listings.
Google specifies that that data may be
given using microdata, microformats or
RDFa.[13] Microdata is specified
inside itemtype and itemprop
attributes added to existing HTML
elements; microformat keywords are
added inside class attributes as
discussed above; and RDFa relies on
rel, typeof and property attributes
added to existing elements.[14]
Because your markup is supposed to be semantic rather than just for display purposes.
Anyone, or anything, that reads your document can immediately tell that a section marked-up with <ul><li>...</li></ul> tags is a list.
CSS doesn't describe what something is, only how it should be rendered. Ideally, you should mark-up your document to describe what each part is, and then use CSS to render those parts appropriately.
Because UL, LI and OL are the HTML elements created with the specific purpose of being lists. By using the proper markup you are adding more information to your content, any automated tool that sees your code will know that those are lists and be able to act accordingly.
If you want links inside a list item, you can put an A element nested inside the LI:
<ul>
<li>Example</li>
</ul>
For those not convinced enough by semantics, I think its fair to also mention that using a list tag can be extended nicely to include second level navigation. Then add in some css (and some javascript for the sake of IE) and bosh... you have superfish menus.
I'm editing books/articles in HTML. These texts were printed once and I scan them, convert them into an intermediate XML-Format and then I transform them into HTML (by XSLT). Because some of those texts are extinct from the market today and are only available through the major libraries I want to publish them in a way so that people could possibly cite them by referring to the page numbers in the original document. For this purpose my intermediate XML-format has an element that marks a page-break. Right now I'm working on the XML->HTML transformations and I'm wondering myself how to transform these page breaks in HTML. They should not appear in the final HTML by default (so a simple | doesn't fit) but I plan to wrap these documents with some lightweight JavaScript that will show the markers when needed. I thought about <span>s with a | in it that are hidden by default.
Is there a better, possibly 'semantic' way to this problem?
Page breaks are very much a thing of layout, and HTML isn't designed to describe layout, so you aren't going to find anything that is semantic for this within the language.
The best you can hope for is some sort of kludge.
Since a page break can occur in the middle of a paragraph, and <p> elements can contain only inline elements you can eliminate most of the options from the outset.
The two possibilities that suggest themselves to me are <span> and <a>. The former has no semantics, that latter is designed to be linked to (with a name attribute) or from (with an href attribute), and you could consider a page from an original document something that you might wish to link to.
No matter what element you use, I wouldn't include a marker in it and then hide it with CSS. That sort of presentational flag is something I would consider adding via :before in a stylesheet (combined with a descendent selector for a body class that can be toggled with JS since you want the toggle)
Alternatively, if you want to take a (very) broad view of the meaning of "HTML" you could consider the l element (from the defunct XHTML 2 drafts) and markup each line of the original document. Adding a class would indicate where a new page began (and you could use CSS counters and borders to clearly indicate each page and number it should you so wish). Pity the browser vendors refused to get behind a real semantic markup language and favoured HTML 5 instead.
Use a <div class="Page"> for each page, and have a stylesheet containing:
.Page {
page-break-after: always;
}
Maybe you can use an xml tag not parsed/interpreted by html like <pagebreak/>.
In this way viewing the html the tag will be not rendered but using jQuery or any other Javascript library, transform, when asked, these particular tags in standard or whatsoever visual mark.
I think this can be a semantic approach...