Is there a programing language that can substitute HTML in making web sites.I don't mean something like ASP,JSP,PHP or similar.Specifically I am looking for a web site programing language which is not based on that line semantics.More specifficaly I' m looking for something that will add the WinForms Coordinates possibility(Positioning elements based on their X and Y axes).Excuse my English,if I made any error.
I hope you understod my question.
There isn't.
However, CSS has absolute positioning that will probably allow you to achieve what you want.
CSS
#box { position: absolute; left: 20px; top: 80px }
HTML
<div id="box"> I am absolutely positioned! </div>
Be advised though that it's often the wrong choice. HTML is fundamentally different from forms based systems, as it's designed to be displayed on a wide choice of different devices.
Maybe show what issue you're dealing with exactly, and ask about that specifically.
No, there isn't.
Web sites are written in HTML.
Most modern browsers understand a number of "languages", CSS, Javascript, XML, XSL and HTML.
Some also support SVG natively.
However it is entirely unclear what you want to.
If all you're looking for is a way to specify the position of elements on a fixed coordinate grid, HTML/CSS support this. You're looking for absolute positioning. Be aware, however, that it's not nearly as cut and dry as it is on, for example, WinForms. Browsers differ, you have little control over the display, etc. It's do-able, but it has a different set of challenges than WinForms does.
Well there's Flash, Java, Silverlight...
You could try Flash:
http://www.adobe.com/devnet/flash.html
You would need html to embed the object, but the plugin space it provides does not use HTML.
Your options are:
HTML5
HTML4 (or less)
Flash
Silverlight
Java (applets)
So while, yes, you do have some options... no, you don't really.
Btw, who ever said that you can't do element/control positioning (a la X,Y coordinates) within HTML? You absolutely can, and it's typically done with CSS and/or JavaScript.
Related
I'm fairly new to HTML. With the rise of HTML5's popularity as a standard (at least, from what I've learned and experience the past couple of semesters), I am wondering if it is still considered good practice to use [DIV] instead of new container elements, such as [main], [nav], etc.
I feel far more comfortable using div's as opposed to the new container tags because of their default values and how much like putty they are when it comes to box modeling a page the way I want it.
My main question is this: If a potential employer or well-seasoned programmer were to look at my HTML5 code and saw div's instead of new container tags, would it be considered bad practice/sloppy coding? Or is using div's still entirely acceptable? Apologies if this is a silly question, but I ask because after this semester is over I'm going to start applying for jobs and want to make sure that my practices/standards are conducive to those that will offer me the highest chance of landing a good employment opportunity!
DIV tags do not convey meaning like you get with the html5 specific section tags. The functionality is the same as far as the block element. Using the new HTML5 tags help self document your code and not need comments to explain what each DIV does.
I would recommend to get into using the new tags in HTML5 instead of just divs. You should always want to write as semantically as possible. This helps you grow as a coder and move the web forward.
Default behavior is a poor reason to not use semantic markup. For one thing, almost every site should use a CSS reset mechanism. Bootstrap, et al, do this for you, and they generally apply border-box sizing for convenience.
Aside from polyfills for older browsers, fallback markup is an option. Wrap a classed div with an HTML5 element and apply CSS to both.
Semantic markup allows other types of content consumption beyond the standard web page, such as syndication feeds and print document generation. HTML5 elements provide much contextual information in those cases, as well as for visually-impaired users who employ screen readers and other assistive technology.
All that said, I doubt many employers will deduct for element choice. Overall page structure, markup cleanliness, appropriate internal documentation, etc. are probably more important.
DIV's are always acceptable, but for a better codding semantic and for the searching engines it's a better practice to use the HTML5 tags. Sooner or later you'll use them so better start practicing.
HTML5 tags are a better way to organize code and help searching engines for best results. It's also help for the CSS because surely you'll save classes and will target the tags.
HTML5 is the way...
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.
I've done a little bit of playing around with the new HTML5 tags and read up on all the new ones at W3cschools, etc. and I'm a little confused.
If I create an HTML page that uses "areas", "sections", "asides", etc. Nothing happens? I have to manually style them - which is FINE, but am I missing something? What's the point of declaring a tag an "aside" if I have to make it ASIDE (common css: float:right;width:30%, sorta thing)?
Why not just stay with DIV tags and style them?
I also noticed new attributes, such as "draggable", but, surprise-surprise, it doesn't drag! I have to code it to drag too (javascript/jquery??) ? What's the point of declaring it draggable? I can create a div tag and drag it using JQuery, so someone please enlighten me as to what's so "whoopty doo" about html5?
This is how the web changes in respect to HTML.
First new tags are created by browser makers for advanced users to try out.
Then they are added to the standard
Then they actually get implemented in the various browsers and devices.
Then they become widespread and useful.
Then they become universal and are implemented by 99.9% of devices.
For the tags mentioned they are probably between steps 2 and 3
It may not be "whoopty doo" but this is how changes occurs in this system
Developers who accept, embrace and use this pattern of evolution help move this process along.
It's a bit zen-like.
Additionally, as Aaron points out in his comment above (+1), these particular tags are semantic tags for organizational/outlining and search engines, screen readers and the like. So you yourself may not see much up front for them.
Might not be the case but at least I know for me I make this mistake every now and then. Don't forget to include at the top <!DOCTYPE html>. Furthermore, not all browsers support HTML5 yet I believe so make sure the browser version you are using supports it (most of them should support it nowadays though).
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?
Is it possible to convert HTML + CSS into HTML for a system that doesn't handle CSS, not even inline CSS?
What options do I have?
No. Much of what CSS does is not possible with HTML alone. Your best option is to design your site in such a way that when it loses CSS, it still renders in a nice and orderly fashion. Pay very close attention to things like Heading Tags, paragraph tags, lists, etc. Be sure to build semantically-correct sites, and they (in most cases) will degrade quite nicely.
The only thing you can do is add styles that were possible with old html3+ attributes and font tags. Quite a bit of stuff is possible, but none of it is going to be automatic. You can go through pretty much everything in css and try to find it's html3+ attribute equivalent.
Things like background font b i center width height are examples of old attributes (or tags in the case of font) that define style (and should generally be ignored these days). I don't envy the work ahead of you, but just make a happy medium between reasonable things and unreasonable styles. Tables also might come in handy for floats as well.
Sounds like an old mobile device?
If you can't use any CSS, I would imagine you would have to resort to possibly deprecated HTML tags/attributes, like font tags and attributes like bgcolor.
This would probably be rather difficult, because to my knowledge you can't achieve everything you can do with CSS, like positioning for example. You would have to switch your layout to use tables and set align, valign, etc.
use this first
http://www.mailchimp.com/labs/inlinecss.php
then replace css with deprecated html
http://www.highdots.com/css-editor/articles/css_equiv.html
Two words: Image Maps :) (I've actually seen sites that, in order to "render correctly on every browser" literally just make a big fancy image the background, and add links accordingly via an image map)