So I've read this article and from what I understand, each native browser widget is actually a combination of basic elements, styling and scripts. This begs the question - if they are consisted of basic building blocks, does that mean that there is a way of customizing them through JavaScript? And I don't mean in the replacement sort of way, as some JavaScript libraries/plugins do - simply by accessing their "Shadow DOM" properties and adding some CSS styles to them, for example. Also, this page has some use cases, but nothing practical.
Anyone ever tried anything like this? Is it possible at all? Downsides?
Thanks.
My main concern would be that the implementations of the shadow DOM would be different between browsers and then you are basically back to needing some sort of library to deal with it. I'm not sure if that is the case, but its worth considering. Also, given that there are so many widget libraries available and that is the standard way of handling most of these issues, is it worth taking on a whole new set of unknown issues instead of just working with known elements?
Related
Is there any harm if custom tags are used and created based on one's choice?
like the one below
<hello>hi there!</hello>
I tried using CSS
hello{
color:red;font-family:arial;
}
The above code works
I have used the above and also can add CSS. is there any harm of doing this, or the CSS features these won't support?
This is purely out of curiosity so don't suggest CSS edits or solutions please.
Why you can't make up elements
It is not valid HTML. Therefore how it behaves will be unpredictable.
It may work in some browsers, currently, but if any of your users visit your site on a different browser, they may get a totally different experience. Further to that, support could be dropped, or change at any time without warning.
Other options for custom elements
It is actually possible to define your own Document Type Definition (DTD), however that too is not a good idea.
Your best bet is to either stick with normal, well-supported HTML elements (see here for list of valid elements), or to use a web component framework, such as Vue, Angular or React, for custom elements/ components.
Don't forget, that you can add the class attribute (as well as others) to any element for styling, so for your use-case, there isn't any need to have additional elements.
My question is similar to what this poster is asking:
What are the concrete risks of using custom HTML attributes?
but I want to know what can happen if I use custom elements and custom attributes with the current html specs (html 5).
Example
<x a="5"> abc </x>
Visually I see no issues in any browser. js works:
x = document.getElementsByTagName('x');
alert('x has attribute a=' + x[0].getAttribute('a'));
css works too:
x{
color: red;
}
x[a]{
text-decoration:underline;
}
Possible Risks include
Backward compatibility. In particular, IE8 and below won't understand your tag, and you'll have to remember to write document.createElement('x') for all your new elements.
Semantics - having your html machine-readable may not be your goal, but there may come a time when it needs to be parsed in a moderately useful fashion.
Portability & maintenance - there are plenty of current html tags that almost certainly do what you want them to do. At some point, someone else may have to look after your code. Is there anything to be gained from having them spend time learning what all your new tags are for?
SEO - don't take the risk of a penalty just because it's something you can do..
For completeness, there are justified reasons to do it though. If you can demonstrate your new tag improves the semantics of your page (your example of 'x' obviously doesn't) and you can think of some use-case where your page will be machine-parsed by your own process, then go for it.
The only issue I can think of is that other applications, including search engines, won't recognize your custom elements and properties, so they won't know what to look for or how to use them which is a decided disadvantage for SEO. Other applications trying to access your content, including RESTful apps, will not know either without you telling the app developer.
This was always listed as one of the disadvantages of XML/XHTML but here we are again, back full circle to where we should have been in the first place, the use of XML on the web ... but I digress.
The main reason custom elements were frowned upon in the past is because browsers don't know what to do with them and there was no standardised way of telling them what they are.
What are the risks of using custom HTML elements in HTML5 without following standardisation?
Browsers will handle them differently:
Some browsers may ignore the elements and pretend they're not there; <x>, I don't know what <x> is, lets get rid of that.
Some browsers may attempt to convert the element into something else; define a <tab> element and a browser may think you've mis-spelled <table>, for instance.
You'd have to handle what the element is supposed to do across a large range of devices; just because it works on your PC doesn't mean it works on your phone, or your TV, or your e-reader... or your WiFi-powered fridge...
The good news is that there is some new documentation being written up to allow developers to define their own custom elements in a standardised way. Custom Elements, as it's titled, gives both developers and browser vendors the know-how to allow developers to implement and script custom elements in a way which will work across all supporting browsers... or that's the idea, anyway.
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
I am trying to disable and hide a checkbox. So the total amount of HTML is small; I can't imagine performance could be an issue.
As far as writing server code goes, the coding work is about the same.
Given these two options, is one better practice than the other? Or does it not matter which I use at all?
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
No, these two options don’t have "exactly the same behavior".
If you hide an element with CSS (display:none), it will still be rendered for
user agents that don’t support CSS (e.g., text browsers), and
user agents that overwrite your CSS (e.g., user style sheets).
So if you don’t need it, don’t include it.
If, for whatever reason, you have to include the element, but it’s not relevant for your document/users (no matter in which presentation), then use the hidden attribute. By using this attribute, you give the information on the HTML level, hence CSS support is not needed/relevant.
You might want to use display:none in addition (this is what many CSS supporting user agents do anyway, but it’s useful for CSS-capable user agents that don’t support the hidden attribute).
You could also use the aria-hidden state in addition, which could be useful for user agents that support WAI-ARIA but not the hidden attribute.
I mean do you need that checkbox? If not then .hide() is just brushing things under the carpet. You are making your HTML cluttered as well as your CSS. However, if it needs to be there then sure, but if you can do without the checkbox then I would not have it in the HTML.
Keep it simple and readable.
The only positive thing I see in hiding it is in the case where you might want to add it back in later as a result of a button being clicked or something else activating it in the page. Otherwise it is just making your code needlessly longer.
For such a tiny scenario the result would be practically the same. But hiding the controls with CSS is IMO not something that you want to make a habit of.
It is always a good idea to make both the code and its output efficient to the point that is practical. So if it's easy for you to not include some controls in the output by adding a little condition everything can be managed tidily, try to do so. Of course this would not extend to the part of your code that receives input, because there you should always be ready to handle any arbitrary data (at least for a public app).
On the other hand, in some cases the code that produces the output is hard to modify; in particular, giving it the capability to determine what to do could involve doing damage in the form of following bad practices: perhaps add a global variable, or else modify/override several functions so that the condition can be transferred through. It's not unreasonable in that case to just add a little CSS in order to again, achieve the solution in a short and localized manner.
It's also interesting to note that in some cases the decision can turn out to be based on hard external factors. For example, a pretty basic mechanism of detecting spambots is to include a field that appears no different in HTML than the others but is made invisible with CSS. In this situation a spambot might fill in the invisible field and thus give itself away.
The confusion point here is this: Why would you ever use display: none instead of simply not render something?
To which the answer is: because you're doing it client side!
"display: none" is better practice when you're doing client side manipulations where the element might need to disappear or reappear without an additional trip to the server. In that case, it is still part of the logical structure of the page and easier to access and manipulate it than remove (and then store in memory in Javascript) and insert it.
However if you're using a server-side heavy framework and always have the liberty of not rendering it, yes, display:none is rather pointless.
Go with "display:none" if the client has to do the work, and manage its relation to the DOM
Go with not rendering it if every time the rendered/not rendered decision changes, the server is generating fresh (and fairly immutable) HTML each time.
I'm not a fan of adding markup to your HTML that cannot be seen and serves no purpose. You didn't provide a single benefit of doing that in your question and so the simple answer is: If you don't need a checkbox to be part of the page, then don't include it in your markup.
I suspect that a hidden checkbox will not add any noticeable time to the download or work by the server. So I agree it's not really a consideration. However, many pages do have extra content (comments, viewstate, etc.) and it can all add up. So anyone with the attitude that they will go ahead and add content that is not needed and never seen by the user, I would expect them to create pages that are noticeably slower overall.
Now, you haven't provided any information about why you might want to include markup that is not needed. Although you said nothing about client script, the one case where I might leave elements in a page that are hidden is when I'm writing client script to remove them. In this case, I may hide() it and leave in the markup. One reason for that is that I could easily show it again if needed.
That's my answer, but I think you'd get a much better answer if you described what considerations you had for including markup on the page that no one will see. Surely, it must offer some benefit that you haven't disclosed or you would have no reason to do it.
Given current HTML5 specs that allows creating custom HTML elements (as long as their name contains a dash), and the fact that Web Components seem to be a feature that's here to stay, I'd like to know why is creating your own custom HTML elements frowned upon?
Note, that I'm not asking whether to use Web Components - which are still a moving target, and even with great polyfills like Polymer might not be ready for production yet. I'm asking about creating your own custom HTML tags and styling them, without attaching any JS APIs to them.
Short answer: I haven't heard any very compelling reasons to avoid them.
However, here are some recurring arguments I've heard made:
Doesn't work in old IE (just document.createElement("my-tag"); should fix that).
Global namespace clashes (same applies to class names, and custom elements in general).
CSS selector performance (doh, this is just about the last thing you should worry about).
Separation of functionality, meaning and presentation. This is actually the only argument I've heard that IMHO has any valid basis to it. You're of course better off with semantic HTML (search engines and all that), but if you were going to use a div for it otherwise, I don't see why you couldn't use a custom tag instead.
One of the arguments against custom tags is their implied incompatibility with screen readers. This issue can be resolved with WAI-ARIA attributes.
There exists an issue in IE11, which breaks table layout if a custom element without display property is inserted inside a table cell. Check the plunker code. Therefore, it's the safest to declare all new elements explicitly, for example like so:
new-element {
display: block;
}
I am currently beginning my forays into HTML and CSS. Already I have become frustrated at the standard box model setup where padding adds to the size of the box itself, so I've set in my CSS templating to use border-box models. Is this ok, or is it not recommended as a best practice / not recommended for learning HTML/CSS? Will many javascript/jQuery scripts break if I use it rather than the standard box model? I don't want to get into the habit of using it if most developers shy away from it or if it will cause pre-made scripts and plugins to break.
The reason I am asking this is because it seems like there are some people who are disgruntled with the current box-model, and if there are any signs that the standard box model might be changing to the border-box model, then I may want to stick with it.
You are asking us if you should use the standard approach, or the non-standard approach. The answer is going to be: use the standard approach. Otherwise, you'll always be fighting CSS.
The best analogy I found for the 'standard' mox model is to pretend you're looking for a box to ship something and need to figure out the space needed. Your object is going to be a certain size, and then you need to leave room for all of your packing materials (the padding).
EDIT:
I admit that I wasn't all that familiar with that CSS property. After doing some research, it does seem to have practical uses (especially when trying to divy up columns in a fluid layout). That said, I wouldn't call it a replacement for the standard box model, but rather an alternative to use when it makes sense to use it. Learn the standard box model, and then you'll know when it makes sense to alter it.
If you use a css reset (as is fairly standard practice) this become much less of an issue.
These are two of the most popular
'The Meyer' - http://meyerweb.com/eric/tools/css/reset/
'YUI Reset' - http://developer.yahoo.com/yui/reset/
These will remove all browser default styling, giving you a 'blank canvas' on which to build. You'll find the majority of CSS frameworks (and most sites) will use a reset of some description. With YUI they even give you another stylesheet to build back some of the removed styles (in a cross browser consistent way).
As for Padding/Margin/Borders specifically (which is what you really asked about in the first place) - it really depends on the context. They exist for different reasons - for example I tend to use margin when spacing divs, and padding when spacing headings but there are no hard and fast rules.